Dale Worley wrote:
> If the registration has a GRUU, it is carried in a <pub-gruu> element
> within the <registration> element.  See
> draft-ietf-sipping-gruu-reg-event-09, soon to be an RFC.

Bob had pointed me to this draft, however I was skeptical about using it since 
it was expired. But, if it is soon to become an RFC it makes sense to follow it.

> 
> A typical example is:
> 
> <?xml version="1.0"?>
> 
> <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
>     xmlns:gr="urn:ietf:params:xml:ns:gruuinfo"
>     version="0" state="full">
>   <registration aor="sip:[EMAIL PROTECTED]" id="as9"
>        state="active">
>     <contact id="76" state="active" event="registered"
>        duration-registered="36001" expires="3599"
>        callid="[EMAIL PROTECTED]" cseq="54321"
>        q="0.8">
>          <uri>sip:[EMAIL PROTECTED]</uri>
>          <unknown-param 
> name="+sip.instance">"&lt;urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6&gt;"</unknown-param>
>          <gr:pub-gruu uri="sip:[EMAIL PROTECTED];gr=hha9s8d-999a"/>
>     </contact>
>   </registration>
> </reginfo>
> 
> (Because the UA provided an instance ID, there is an <unknown-param
> name="+sip.instance"> element as well.)
> 
> (Oddly, a registrar can construct a GRUU for a registration even if the
> UA doesn't support GRUU.  Because the registrar/proxy converts the GRUU
> to the contact of the UA, the UA can receive requests directed to the
> GRUU.)
> 

This explains why the LG-Nortels have a GRUU address assigned to them by the 
registrar. But, I believe only phones that provide an instance id will be 
assigned a GRUU right now.


> Summarizing this discussion, if a UA registers with a Path and is issued
> a GRUU, the <reginfo> will look like this:
> 
> <?xml version="1.0"?>
> <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
>          xmlns:gr="urn:ietf:params:xml:ns:gruuinfo"
>        version="1" state="partial">
>   <registration aor="sip:[EMAIL PROTECTED]" id="a7" state="active">
>     <contact id="76" state="active" event="registered"
>            duration-registered="100">
>        <uri>sip:[EMAIL PROTECTED]</uri>
>        <unknown-param name=path>sip:my.path.com</unknown-param> 
>        <gr:pub-gruu uri="sip:[EMAIL PROTECTED];gr=hha9s8d-999a"/>
>     </contact>
>   </registration>
> </reginfo>
> 

Did you leave out the <unknown-param name="+sip.instance"> element on purpose? 

> (Note that values of the Path header are name-addr's (see RFC 3327
> section 4, and so the "sip:" at the beginning of the value may not be
> omitted, as has been done in several examples in this thread.)
> 

Thanks for pointing that out!

> The recipient of this document can access this UA via
> "sip:[EMAIL PROTECTED];gr=hha9s8d-999a", or
> "sip:[EMAIL PROTECTED]:my.path.com", or
> "sip:[EMAIL PROTECTED]", depending on which components of reginfo it
> understands.  The first is preferable to the second, and the third may
> not work.
> 

Now, I take it that in this case you mean the GRUU address is "hha9s8d-999a", 
and "[EMAIL PROTECTED]" is the"[EMAIL PROTECTED]"?

I tested constructing the request using just the GRUU, against the LG-Nortels. 
The request is correctly routed to the registrar, where the request-URI is 
replaced by the phone's contact address. However, the GRUU address is still 
present in the To header, and the phone chokes on that. 


Arjun


_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev

Reply via email to