You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@bklang When registering, the To header needs to contain the AoR to which we are registering, it's typically the same as the From, unless third-party registration is taking place.
About GRUU. When using GRUU, one needs to indicate the instance id in the contact header:
Now, if the proxy supports GRUU and someone dials sip:[email protected];gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 only this instance will ring, it will not fork.
The text was updated successfully, but these errors were encountered:
So to your question about GRUU, we would need to modify the Contact header in the REGISTER request to include a supplied UUID? I think we can accommodate that.
Yes, oh, and also add a "Supported: gruu" header, that will do. If the server supports GRUU it will send them in the 200 OK, else you'll get the usual response.
In case you want to know all the details: http://tools.ietf.org/html/rfc5627#section-9 but there is not much to it from the client side.
From @saghul:
@bklang When registering, the To header needs to contain the AoR to which we are registering, it's typically the same as the From, unless third-party registration is taking place.
About GRUU. When using GRUU, one needs to indicate the instance id in the contact header:
Then the 200 OK will contain the public and temporary GRUUs, if supported:
Now, if the proxy supports GRUU and someone dials
sip:[email protected];gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
only this instance will ring, it will not fork.The text was updated successfully, but these errors were encountered: