Yes,

Verified, 'gruu_enabled' is set to one.

Regards

2012/7/27 Daniel-Constantin Mierla miconda@gmail.com

Hello,

just to be sure before going to any further investigation (as I remember, such case I tested a bit with some command line tools due to lack of a sip phone with good ob/gruu support), do you have in the config:

modparam("registrar", "gruu_enabled", 1)

The default config file in 3.3, has the parameter set to 0.

Cheers, Daniel

On 7/27/12 10:05 AM, Iñaki Baz Castillo wrote:

...

Hi, full agree with this bug report. Adding the devel maillist. More comments at the end of the mail:

2012/7/26 José Luis Millán jmillan@aliax.net:

...

Hi,

I'm using Kamilio 3.3.0 as registrar server. I`m using an outbound proxy so 'use_path' parameter or 'registrar' module is enabled.

According to RFC 5626, a re-registration from a specific combination of AoR, instance_id and reg_id must update the binding.

"" If the registrar receives a re-registration for a specific combination of AOR, and instance-id and reg-id values, the registrar MUST update any information that uniquely identifies the network flow over which the request arrived if that information has changed, and SHOULD update the time the binding was last updated. ""

In my installation this is not fullfilled as shown:

"" AOR:: jmillan Contact:: sip:jmillan@MY_IP;transport=**ws;ov-ob=a570655c14 Q= Expires:: 181 Callid:: 1hgq3khalq2rzfr Cseq:: 108 User-agent:: JsSIP 0.1.0 Path:: sip:OUTBOUND_IP:9090;**transport=tcp;lr;ovid=** de0c0b9f,sip:a570655c14@**OUTBOUND_IP:10080;transport=** ws;lr;ovid=de0c0b9f;ob State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: tcp:KAM_IP:5060 Methods:: 783 Ruid:: uloc-50119d99-328e-1 Instance:: urn:uuid:38dce009-ae1f-4fd1-**91dc-99ed9affddc1 Reg-Id:: 1 Contact:: sip:jmillan@MY_IP;transport=**ws;ov-ob=1dd97b4d51 Q= Expires:: 193 Callid:: 1hgq3khalq2rzfr Cseq:: 110 User-agent:: JsSIP 0.1.0 Path:: sip:OUTBOUND_IP:9090;**transport=tcp;lr;ovid=** de0c0b9f,sip:1dd97b4d51@**OUTBOUND_IP:10080;transport=** ws;lr;ovid=de0c0b9f;ob State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: tcp:KAM_IP:5060 Methods:: 783 Ruid:: uloc-50119d99-3290-2 Instance:: urn:uuid:38dce009-ae1f-4fd1-**91dc-99ed9affddc1 Reg-Id:: 1 ""

The scenario is such that when the client looses the connection with the Outbound Server, it reconnects and re-registers to Kamailio in order to replace registration and be able to receive in-dialog messages.

Receiving in-dialog requests should work since GRUU is also being used. The problem is that the new REGISTER (after UA disconnection) does not update the previous one (as this thread reports) so Kamailio still chooses the previous binding which does not work anymore.

Regards.

-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/**micondahttp://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw

______________________________**_________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

After playing a bit more with it, I pushed some commits on master branch. Can you try to see if they fixed the issue you reported?

Cheers, Daniel

On 7/30/12 12:06 PM, Daniel-Constantin Mierla wrote:

Hello,

can you send the requests for registration and re-registration (ngrep with -W byline or pcap) in order to test them here? I tried to reproduce with an UA I have here and the registration update does the right thing.

Cheers, Daniel

On 7/27/12 1:43 PM, José Luis Millán wrote:

...

Yes,

Verified, 'gruu_enabled' is set to one.

Regards

2012/7/27 Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com>

Hello,

just to be sure before going to any further investigation (as I
remember, such  case I tested a bit with some command line tools
due to lack of a sip phone with good ob/gruu support), do you
have in the config:

modparam("registrar", "gruu_enabled", 1)

The default config file in 3.3, has the parameter set to 0.

Cheers,
Daniel


On 7/27/12 10:05 AM, Iñaki Baz Castillo wrote:

    Hi, full agree with this bug report. Adding the devel
    maillist. More
    comments at the end of the mail:


    2012/7/26 José Luis Millán <jmillan@aliax.net
    <mailto:jmillan@aliax.net>>:

        Hi,

        I'm using Kamilio 3.3.0  as registrar server. I`m using
        an outbound proxy so
        'use_path' parameter or 'registrar' module is enabled.

        According to RFC 5626, a re-registration from a specific
        combination of AoR,
        instance_id and reg_id must update the binding.

        ""
            If the registrar receives a re-registration for a
        specific
            combination of AOR, and instance-id and reg-id
        values, the registrar
            MUST update any information that uniquely identifies
        the network flow
            over which the request arrived if that information
        has changed, and
            SHOULD update the time the binding was last updated.
        ""

        In my installation this is not fullfilled as shown:

        ""
                 AOR:: jmillan
                         Contact::
        sip:jmillan@MY_IP;transport=ws;ov-ob=a570655c14 Q=
                                 Expires:: 181
                                 Callid:: 1hgq3khalq2rzfr
                                 Cseq:: 108
                                 User-agent:: JsSIP 0.1.0
                                 Path::
        <sip:OUTBOUND_IP:9090;transport=tcp;lr;ovid=de0c0b9f>,<sip:a570655c14@OUTBOUND_IP:10080;transport=ws;lr;ovid=de0c0b9f;ob>
                                 State:: CS_SYNC
                                 Flags:: 0
                                 Cflag:: 0
                                 Socket:: tcp:KAM_IP:5060
                                 Methods:: 783
                                 Ruid:: uloc-50119d99-328e-1
                                 Instance::
        <urn:uuid:38dce009-ae1f-4fd1-91dc-99ed9affddc1>
                                 Reg-Id:: 1
                         Contact::
        sip:jmillan@MY_IP;transport=ws;ov-ob=1dd97b4d51 Q=
                                 Expires:: 193
                                 Callid:: 1hgq3khalq2rzfr
                                 Cseq:: 110
                                 User-agent:: JsSIP 0.1.0
                                 Path::
        <sip:OUTBOUND_IP:9090;transport=tcp;lr;ovid=de0c0b9f>,<sip:1dd97b4d51@OUTBOUND_IP:10080;transport=ws;lr;ovid=de0c0b9f;ob>
                                 State:: CS_SYNC
                                 Flags:: 0
                                 Cflag:: 0
                                 Socket:: tcp:KAM_IP:5060
                                 Methods:: 783
                                 Ruid:: uloc-50119d99-3290-2
                                 Instance::
        <urn:uuid:38dce009-ae1f-4fd1-91dc-99ed9affddc1>
                                 Reg-Id:: 1
        ""

        The scenario is such that when the client looses the
        connection with the
        Outbound Server, it reconnects and re-registers to
        Kamailio in order to
        replace registration and be able to receive in-dialog
        messages.

    Receiving in-dialog requests should work since GRUU is also being
    used. The problem is that the new REGISTER (after UA
    disconnection)
    does not update the previous one (as this thread reports) so
    Kamailio
    still chooses the previous binding which does not work anymore.


    Regards.





-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -
http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -
http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -
http://asipto.com/u/kpw



_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw

Hi Daniel

It works as expected. Binding is updated correctly now!

Thank you very much.

Regards

2012/7/30 Iñaki Baz Castillo ibc@aliax.net

2012/7/30 Daniel-Constantin Mierla miconda@gmail.com:

...

After playing a bit more with it, I pushed some commits on master branch. Can you try to see if they fixed the issue you reported?

Hi Daniel, we are testing it. It looks ok for now but we need further testing, please let us giving a better feedback today or tomorrow.

Thanks a lot.

-- Iñaki Baz Castillo ibc@aliax.net

2012/7/30 Peter Dunkley peter.dunkley@crocodile-rcs.com

With these changes (and a client that supports it) should I now be able to use WebSockets without the aliasing from nathelper?

Hi, there should be no difference with the case of SIP over TCP or TLS. The main benefict of using Outobund and GRUU in clients (with reliable transport such as TCP/TLS/WS) is that when the UA is in an active dialog and its connection is closed, it can re-register (using a GRUU Contact), replace the previous binding in the registrar, and when an incoming request from the dialog peer arrives to the registrar it chooses the last created binding for that GRUU Contact, so the request arrives to the UA even through its new connection.

BTW I *hate* Contact mangling and Contact aliasing, that's an ugly mechanism. Outbound solves that perfectly.

Regards.

Hello,

On 7/30/12 6:51 PM, Peter Dunkley wrote:

Hi Iñaki,

I'll stop using the mangling and aliasing as soon as Kamailio supports Outbound. But for now... it works :-)

for such scenario, the gruu support is enough -- the problem is selecting the right destination address in case of natted contacts. This gruu extension is implemented in kamailio, but the big problem is client side support -- very few SIP soft/hard phones implement it.

From the outbound, the missing part is automatic failover over multiple streams (i.e., same sip instance but different reg-id values) -- this is related to the situation when same UA registers via multiple paths in order to be reachable when one path is down (say reg-id=1 main one is not working, then try flow with reg-id=2 even for requests within dialog) . It might be possible to be done via config file operations, by serializing branches, although never tried, some pieces might still be needed to be coded. Registering multiple flows is already possible at this time, the key being (sip.instance, reg-id) when gruu is enabled and supported by UA, advertised in the headers.

There is one situation that will not work even with gruu/ob -- in sip a phone can call without registering. A gruu contact is obtained via registration and then used for next requests by UA itself. By calling without registering, there is no gruu contact for it, so adding the src ip and port as alias parameter is still needed. I don't remember I have seen any rfc making registration mandatory before calling.

In other words, just to summarize the gruu versus contact aliasing. Gruu allocates an unique token for a SIP UA, mapping it to location record where source ip and port are stored in memory/database, then looked up when needed based on this token (even for request within dialog the lookup() function has to be executed). Contact aliasing is storing the source ip and port as a parameter to contact header to be processed from the request itself, where it will be part of R-URI for requests within dialog.

Cheers, Daniel

Peter

...

2012/7/30 Peter Dunkley peter.dunkley@crocodile-rcs.com

...

With these changes (and a client that supports it) should I now be able to use WebSockets without the aliasing from nathelper?

Hi, there should be no difference with the case of SIP over TCP or TLS. The main benefict of using Outobund and GRUU in clients (with reliable transport such as TCP/TLS/WS) is that when the UA is in an active dialog and its connection is closed, it can re-register (using a GRUU Contact), replace the previous binding in the registrar, and when an incoming request from the dialog peer arrives to the registrar it chooses the last created binding for that GRUU Contact, so the request arrives to the UA even through its new connection.

BTW I *hate* Contact mangling and Contact aliasing, that's an ugly mechanism. Outbound solves that perfectly.

Regards.

-- Iñaki Baz Castillo ibc@aliax.net

Hello,

On 7/30/12 5:21 PM, Iñaki Baz Castillo wrote:

2012/7/30 Daniel-Constantin Mierla miconda@gmail.com:

...

After playing a bit more with it, I pushed some commits on master branch. Can you try to see if they fixed the issue you reported?

Hi Daniel, we are testing it. It looks ok for now but we need further testing, please let us giving a better feedback today or tomorrow.

Thanks a lot.

quick question to double check if what I understood when I read the specs was ok -- in gruu/ob, it does not matter anymore the callid/cseq combination, or there should still be some checks related to it?

Cheers, Daniel

Hello,

On 7/30/12 7:23 PM, Iñaki Baz Castillo wrote:

2012/7/30 Daniel-Constantin Mierla miconda@gmail.com:

...

quick question to double check if what I understood when I read the specs was ok -- in gruu/ob, it does not matter anymore the callid/cseq combination, or there should still be some checks related to it?

In fact that depends on Outbound instead of GRUU, and not, when using Outbound the registrar does NOT check the Call-ID and CSeq of the REGISTER (and using GRUU means that Outbound is also used, so the Contact has a +sip.instance and reg-id params which are inspected by the registrar to create/update/delete a binding).

but what about same callid with lower cseq, combined with same sip instance and reg-id? Cheers, Daniel

Hello,

What I am trying to work out is whether Kamailio now supports enough of Outbound and GRUU that the contact aliasing I am using with WebSockets is no longer necessary?

Also, is the current support complete enough that there are no issues around WebSocket connections being broken and the client re-registering (effectively replacing the existing contact binding)?

I believe for WebSockets the situation is exactly the same as you would have for a client connecting over TCP from behind a NAT.

Regards,

Peter

On Tue, 2012-07-31 at 13:59 +0200, José Luis Millán wrote:

Hi,

Outbound provides the UAC a way to update a binding even if it reboots. For that, a unique and permanent value of instance-id is used, which in conjunction with the AoR and reg-id determines the binding to the UAC.

Having said this, I guess that the CSeq comparison between the one in the Register request and the one in the binding does not apply in this scenario since it is not guaranteed that a UAC saves the CSeq value of the registration among reboots.

Regards.

2012/7/31 Daniel-Constantin Mierla miconda@gmail.com

    Hello,



    On 7/30/12 7:23 PM, Iñaki Baz Castillo wrote:

            2012/7/30 Daniel-Constantin Mierla
            <miconda@gmail.com>:

                    quick question to double check if what I
                    understood when I read the specs
                    was ok -- in gruu/ob, it does not matter
                    anymore the callid/cseq
                    combination, or there should still be some
                    checks related to it?

            In fact that depends on Outbound instead of GRUU, and
            not, when using
            Outbound the registrar does NOT check the Call-ID and
            CSeq of the
            REGISTER (and using GRUU means that Outbound is also
            used, so the
            Contact has a +sip.instance and reg-id params which
            are inspected by
            the registrar to create/update/delete a binding).

    but what about same callid with lower cseq, combined with same
    sip instance and reg-id?


    Cheers,
    Daniel


    _______________________________________________
    sr-dev mailing list
    sr-dev@lists.sip-router.org
    http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

2012/7/31 José Luis Millán jmillan@aliax.net:

Outbound provides the UAC a way to update a binding even if it reboots. For that, a unique and permanent value of instance-id is used, which in conjunction with the AoR and reg-id determines the binding to the UAC.

Having said this, I guess that the CSeq comparison between the one in the Register request and the one in the binding does not apply in this scenario since it is not guaranteed that a UAC saves the CSeq value of the registration among reboots.

This is correct. According to RFC 5626, when the REGISTER includes a Contact with +sip.instance and reg-id params the registrar MUST NOT check the call-id and cseq of the request, but just the +sip.instance and reg-id params (and the registering AoR in the To header of course).