OK,

I think this should be working now. Please let me know if there are problems.

One thing I have done here is remove outbound completely from the strict routing code. I don't have a system to test this with at the moment and what was there wouldn't have worked. If anyone thinks they might use outbound and strict routing in the same network they are welcome to try adding it back ;-)

Regards,

Peter

On 24/04/13 11:47, Peter Dunkley wrote:

Hi,

I've started fixing this now.

I have updated the record-routing part so that double-RRs are added. I now have to modify the strict and loose routing code in loose.c to do the right thing when double-RRs with flow-tokens are received.

Hopefully, should have something within the next day or so.

Regards,

Peter

On 22/04/13 13:55, Peter Dunkley wrote:

...

Hi Juha,

As you said the fix is not trivial. I may have need for this myself so I may do it soon, but I can't give any indication as to when.

Regards,

Peter

On 22/04/13 13:44, Juha Heinanen wrote:

...

peter,

do you think you would have time in near future to re-instate double record-routing also when outbound is in use?

since the fix is not trivial, i'm afraid to try it myself.

-- juha

---

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

---

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

---

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

Thanks,

I'll start back-porting these to 4.0 as that should make the ob edge proxy stuff there work properly too.

Peter

Peter Dunkley writes:

...

I think this should be working now. Please let me know if there are problems.

i made some tests that involved outbound and non-outbound clients and they all worked fine.

i'll make tomorrow more tests with clients that support both outbound and gruu.

-- juha

---

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

Peter Dunkley writes:

I think this should be working now. Please let me know if there are problems.

peter,

i made some tests with client that supports both ob and gruu in this kind of setup:

caller ua -- proxy/registrar 1 -- proxy/registrar 2 -- callee ua

when invite comes to proxy/registrar 1 it has "Supported: gruu, outbound, path" and ;gr param in contact uri. proxy/registrar 1 then calls record_route() on the invite and forwards it to proxy/registrar 2.

ngrep shows that record_route() added these two r-r headers:

Record-Route: sip:8ESgMbGAnoV8swXAYmYKJ2DAYmgC6dc=@192.98.102.10:5070;transport=tcp;r2=on;lr. Record-Route: sip:8ESgMbGAnoV8swXAYmYKJ2DAYmgC6dc=@192.98.102.10:10080;transport=ws;r2=on;lr.

because caller ua supports gruu, in-dialog requests to it should be routed based on gruu lookup, not based on flow token in route header. so i don't see the point in record_route() including the flow tokens to r-r uris.

now when callee ua sends bye, it gets handled in proxy/registrar 1 like this:

Apr 25 08:49:01 siika /usr/sbin/sip-proxy[12538]: INFO: calling loose_route() on route <sip:8ESgMbGAnoV8swXAYmYKJ2DAYmgC6dc=@192.98.102.10:5070;transport=tcp;r2=on;lr> Apr 25 08:49:01 siika /usr/sbin/sip-proxy[12538]: INFO: ru/du = sip:jh@test.fi;gr=urn:uuid:e88f32f1-b837-43be-8955-bc606d626252;ob/sip:192.98.104.2:59863;transport=ws Apr 25 08:49:01 siika /usr/sbin/sip-proxy[12538]: INFO: Routing in-dialog BYE sip:jh@test.fi;gr=urn:uuid:e88f32f1-b837-43be-8955-bc606d626252;ob from sip:test@test.fi to sip:192.98.104.2:59863;transport=ws

that is, loose_route() set $du and since $du is set, gruu lookup does not take place.

i'm not sure what is the best way to fix this. one way could be to add some param in record_route() that tells it not to use flow tokens.

-- juha

Or use something like "add_rr_param()" to stick in a custom header yourself in the Kamailio configuration and then check for it in Route: headers and decide whether to bypass calling loose_route() or not based on it.

On 25/04/13 10:10, Peter Dunkley wrote:

If you don't want Record-Route:/Route: based routing why not just not add the Record-Route:s?

Regards,

Peter

On 25/04/13 07:01, Juha Heinanen wrote:

...

Peter Dunkley writes:

...

I think this should be working now. Please let me know if there are problems.

peter,

i made some tests with client that supports both ob and gruu in this kind of setup:

caller ua -- proxy/registrar 1 -- proxy/registrar 2 -- callee ua

when invite comes to proxy/registrar 1 it has "Supported: gruu, outbound, path" and ;gr param in contact uri. proxy/registrar 1 then calls record_route() on the invite and forwards it to proxy/registrar 2.

ngrep shows that record_route() added these two r-r headers:

Record-Route: sip:8ESgMbGAnoV8swXAYmYKJ2DAYmgC6dc=@192.98.102.10:5070;transport=tcp;r2=on;lr. Record-Route: sip:8ESgMbGAnoV8swXAYmYKJ2DAYmgC6dc=@192.98.102.10:10080;transport=ws;r2=on;lr.

because caller ua supports gruu, in-dialog requests to it should be routed based on gruu lookup, not based on flow token in route header. so i don't see the point in record_route() including the flow tokens to r-r uris.

now when callee ua sends bye, it gets handled in proxy/registrar 1 like this:

Apr 25 08:49:01 siika /usr/sbin/sip-proxy[12538]: INFO: calling loose_route() on route <sip:8ESgMbGAnoV8swXAYmYKJ2DAYmgC6dc=@192.98.102.10:5070;transport=tcp;r2=on;lr> Apr 25 08:49:01 siika /usr/sbin/sip-proxy[12538]: INFO: ru/du = sip:jh@test.fi;gr=urn:uuid:e88f32f1-b837-43be-8955-bc606d626252;ob/sip:192.98.104.2:59863;transport=ws

Apr 25 08:49:01 siika /usr/sbin/sip-proxy[12538]: INFO: Routing in-dialog BYE sip:jh@test.fi;gr=urn:uuid:e88f32f1-b837-43be-8955-bc606d626252;ob from sip:test@test.fi to sip:192.98.104.2:59863;transport=ws

that is, loose_route() set $du and since $du is set, gruu lookup does not take place.

i'm not sure what is the best way to fix this. one way could be to add some param in record_route() that tells it not to use flow tokens.

-- juha

---

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

---

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

I am saying that record-route()/loose_route() doesn't do anything with GRUU when outbound is used right now.

I am not sure what the right changes would be. But there might be something easy you can do to avoid the problem for now.

Changing the code to add a custom parameter isn't a good idea as it will be outside of any RFC specification. I think whatever is in the code should be based on the RFCs. So if you want to do something to work around it with custom parameters as you have suggested I think this should be done entirely on the config file side of things.

Regards,

Peter

On 25/04/13 10:24, Juha Heinanen wrote:

Peter Dunkley writes:

...

If you don't want Record-Route:/Route: based routing why not just not add the Record-Route:s?

i didn't understand. i have to add record-router header pointing to proxy/registrar 1 when invite is forwarded to proxy/registrar 2. without gruu this has worked fine just by calling record_route().

are you now suggesting that gruu cannot be handled automatically by record_route() call and that i need to use record_route_preset(string [,string2]) instead?

-- juha

---

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

Juha Heinanen writes:

there could be some way to tell to record_route() that it should not add flow token to r-r uri(s) no matter if outbound is supported by the incoming request.

for example, there could be an rr module flag that tells if record_route() should not include a flow token in r-r uri(s).

proxy could set the flag before calling record_route() if request comes from local user and contact uri contains a gruu.

-- juha

Feel free to add it if you think it'll solve your problem.

Regards,

Peter

On 25/04/13 11:23, Juha Heinanen wrote:

Juha Heinanen writes:

...

for example, there could be an rr module flag that tells if record_route() should not include a flow token in r-r uri(s).

outbound module already has force_outbound_flag. there could be an opposite flag, for example, no_outbound_flag.

-- juha

---

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

there is also problem with registrar save(). when edge proxy forwards register request to registrar, it adds path header. if register request supports gruu, path header should not contain flow token, but if it does not, i get error

Apr 25 14:38:32 wheezy1 /usr/sbin/sip-proxy[3637]: WARNING: registrar [save.c:917]: Outbound used by UAC but not supported by edge proxy

i would like to change the test so that warning comes only if gruu is not supported:

if (use_ob == 0) { if ((get_supported(_m) & F_OPTION_TAG_OUTBOUND) && contact->reg_id) { if (!(get_supported(_m) & F_OPTION_TAG_GRUU)) { LM_WARN("Outbound used by UAC but not supported by edge proxy\n"); rerrno = R_OB_UNSUP_EDGE; goto error; } } else { /* ignore ;reg-id parameter */ use_regid = 0; } }

-- juha

Peter Dunkley writes:

Are GRUU and outbound really mutually exclusive in this way?

my understanding is that outbound flow token is added to route set when dialog is established. if ua looses connection to its proxy during the dialog and then re-establishes it, in-dialog requests to that ua stop working based on the flow token. if ua supports gruu, then that problem does not exist, because in-dialog requests are routed to the ua based on location lookup.

have i missed something?

-- juha

If the edge proxy does not add a flow-token to the Path: header how will INVITEs ever get to client devices behind NATs?

The location record in the registrar will not contain a valid (NAT aware) route back to the client.

Regards,

Peter

On 25/04/13 16:02, Juha Heinanen wrote:

Juha Heinanen writes:

...

i would like to change the test so that warning comes only if gruu is not supported:

if (use_ob == 0) {
	if ((get_supported(_m) & F_OPTION_TAG_OUTBOUND)
	        && contact->reg_id) {
	        if (!(get_supported(_m) & F_OPTION_TAG_GRUU)) {
		        LM_WARN("Outbound used by UAC but not supported by edge proxy\n");
		        rerrno = R_OB_UNSUP_EDGE;
		        goto error;
	        }
	} else {
		/* ignore ;reg-id parameter */
		use_regid = 0;
	}
}

actually, it would be better for the edge proxy in gruu case to add ;ob param to path header, but leave out flow token. that way, the operation would be fully conforming to outbound rfc.

-- juha

---

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

But isn't the received parameter stuff on Path: a Kamailio proprietary solution? I thought the outbound flow-token was the correct way to do that on Path:?

On 25/04/13 17:00, Juha Heinanen wrote:

Peter Dunkley writes:

...

If the edge proxy does not add a flow-token to the Path: header how will INVITEs ever get to client devices behind NATs?

they do, because when ua behind NAT registers, edge proxy adds received param to path header that contains the ip address/port of the ua at the nat box.

i just tested and it worked fine.

register from edge proxy to registrar (note received in path header):

Session Initiation Protocol Request-Line: REGISTER sip:test.fi SIP/2.0 Message Header Via: SIP/2.0/TCP 192.98.102.10:5070;branch=z9hG4bKf1e.275e3219c0b2e50b00e32ce46abf509c.0 Via: SIP/2.0/WS lkh33af7k3up.invalid;rport=62121;received=192.98.104.2;branch=z9hG4bK2333142 Max-Forwards: 16 To: sip:jh@test.fi From: "Juha Heinanen" sip:jh@test.fi;tag=hesufr3300 Call-ID: fv0rqlp5tcdv2uden3grb6 CSeq: 88 REGISTER Contact: sip:rebu3li2@lkh33af7k3up.invalid;transport=ws;reg-id=1;+sip.instance="urn:uuid:480356d7-8507-4ad8-bf27-292d463224f2";expires=600 Allow: ACK,CANCEL,BYE,OPTIONS,INVITE,MESSAGE Supported: path, outbound, gruu User-Agent: JsSIP 0.3.0 Content-Length: 0 Path: sip:192.98.102.10:5070;transport=tcp;lr;received=sip:192.98.104.2:62121%3Btransport%3Dws

invite from registrar/home proxy to edge proxy (note route header containing received):

Session Initiation Protocol Request-Line: INVITE sip:rebu3li2@lkh33af7k3up.invalid;transport=ws SIP/2.0 Message Header Record-Route: sip:192.98.102.20:5070;transport=tcp;r2=on;lr Record-Route: sip:192.98.102.20;transport=tcp;r2=on;lr Via: SIP/2.0/TCP 192.98.102.20:5070;branch=z9hG4bKd777.2d854da9ddf108b1a4f6278cdd384c2b.0;i=2 Via: SIP/2.0/TCP 192.98.102.10:5064;branch=z9hG4bKbd2c5fb6ce49eaec;rport=51603 Contact: sip:0x262d610@192.98.102.10:5064;alias=192.98.102.10~51603~2;transport=tcp Max-Forwards: 16 Route: sip:192.98.102.10:5070;transport=tcp;lr;received=sip:192.98.104.2:62121%3Btransport%3Dws To: sip:jh@test.fi From: "" sip:test@test.fi;tag=c8c7348f9ae4a7d4 Call-ID: 4095ecb4e893586f CSeq: 33849 INVITE User-Agent: baresip v0.4.3 (x86_64/linux) Allow: INVITE,ACK,BYE,CANCEL,REFER,NOTIFY,SUBSCRIBE,INFO Content-Type: application/sdp Content-Length: 521 P-Asserted-Identity: sip:+35852345671@test.fi Message Body

-- juha

---

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

Peter Dunkley writes:

I don't understand (functionally) what the difference between a flow-token in a Path: header and the received parameter is. So I don't understand why a flow-token can't be put in a Path: header when using GRUU.

most likely you are correct, i.e., there is no problem with flow token in path header of register request as long as there is a way to avoid flow token in r-r uris.

-- juha

Peter Dunkley writes:

I think you have that now by using your new flag?

yes, i tested that adding flow token to register path is ok and i can prevent adding of flow token by force_no_outbound_flag when initial request has gruu in contact uri.

-- juha