22 Apr
2013
22 Apr
'13
3:44 p.m.
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
22 Apr
22 Apr
3:55 p.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
24 Apr
24 Apr
1:47 p.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
6:37 p.m.
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:
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev 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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
9:55 p.m.
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:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
10:13 p.m.
Actually, looking at it, some of the outbound module fixes rely on some of
the recent changes made to the supported/require parser so I won't
back-port this for now as it looks to be a bigger job than I have time to
do and test right now.
Peter
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
Technical Director
Crocodile RCS Ltd
Peter Dunkley writes:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
25 Apr
25 Apr
9:01 a.m.
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
12:10 p.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
12:13 p.m.
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:
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev 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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
12:24 p.m.
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
12:28 p.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
12:56 p.m.
Peter Dunkley writes:
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.
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.
-- juha
1:11 p.m.
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
1:49 p.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
1:56 p.m.
Peter Dunkley writes:
Feel free to add it if you think it'll solve your
problem.
doing it right now, but i don't think this is just my problem. there
should be an easy way (also included in example config) to correctly
handle user agents that support both outbound and gruu.
-- juha
3:13 p.m.
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
3:16 p.m.
Are GRUU and outbound really mutually exclusive in this way?
On 25/04/13 13:13, Juha Heinanen wrote:
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
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
3:31 p.m.
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
6:02 p.m.
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
6:22 p.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
7 p.m.
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
8:03 p.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
8:13 p.m.
I was under the impression that one advantage of outbound is that is
replaced the need for non-standard solutions such as contact-aliasing
and adding received headers to things like Path:
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. I can see that you don't need to put flow-tokens in Record-Route:
headers when using GRUU because the route-set used for in-dialog routing
will be based on the Path: stored in the location table - but it seems
to me that this makes putting the outbound flow-token in to the Path:
headers essential.
Regards,
Peter
On 25/04/13 18:03, Peter Dunkley wrote:
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:
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev 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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
8:21 p.m.
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
8:28 p.m.
I think you have that now by using your new flag?
On 25/04/13 18:21, Juha Heinanen wrote:
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
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
4229
days inactive
4232
days old
27 comments
2 participants
participants (2)
-
Juha Heinanen -
Peter Dunkley