3 May
2013
3 May
'13
6:13 p.m.
Hi
My application is for mobile (MVNO) users making calls, which will generally end up on the
PSTN via our carriers.
MVNO Carrier --> Our Edge Switch --> Our PSTN Switch --> Our
carrier's switch
|
|---> Our internal routing switch
The issue is with our PSTN switch and the fact that it is not staying in the SIP
signalling path, so when the call ultimately between our MVNO carrier and outbound Carrier
is established (200 OK) the MVNO carrier and PSTN carrier begin talking to each other.
When the MVNO carrier issues a BYE to the outbound carrier, the outbound carrier does not
then receive this packet as they are firewalled (and always will be).
What is the correct method of relaying calls through Kamailio but not passing on the
Contact: header info? I have read that forcing a change of Contact is not the right way.
Leo
3 May
3 May
6:29 p.m.
Am Freitag, 3. Mai 2013, 16:13:36 schrieb Leo Brown:
[..]
MVNO Carrier --> Our Edge Switch --> Our PSTN Switch --> Our
carrier's switch
|---> Our internal routing
|switch
The issue is with our PSTN switch and the fact that it is not staying in the
SIP signalling path, so when the call ultimately between our MVNO carrier
and outbound Carrier is established (200 OK) the MVNO carrier and PSTN
carrier begin talking to each other.
When the MVNO carrier issues a BYE to the outbound carrier, the outbound
carrier does not then receive this packet as they are firewalled (and
always will be).
What is the correct method of relaying calls through Kamailio but not
passing on the Contact: header info? I have read that forcing a change of
Contact is not the right way.
Hello,
if you want to ensure that your kamailio stays on the path of the dialog for
following requests you probably want to use record-route headers for this.
This is usally done with the rr module, record_route() function.
To quote from iptel.org:
"[A] Mechanism by which a proxy can inform user agents that it wishes to stay
on the path of all further messages is called record routing. Such a proxy
would insert Record-Route header field into SIP messages which contain address
of the proxy. Messages sent within a dialog will then traverse all SIP proxies
that put a Record-Route header field into the message.
The recipient of the request receives a set of Record-Route header fields in
the message. It must mirror all the Record-Route header fields into responses
because the originator of the request also needs to know the set of proxies."
Best regards,
Henning Westerholt
6:33 p.m.
Ace,
So record-route goes like a stack and moves the current contact one down the chain.
You could then presumably truncate the list of other routes for privacy if needed?
I don't see why all "record-route" entries need to be maintained if the
conversation is mediated by Kamailio.
Leo
On 3 May 2013, at 16:29, Henning Westerholt <hw(a)kamailio.org> wrote:
if you want to ensure that your kamailio stays on the
path of the dialog for
following requests you probably want to use record-route headers for this.
This is usally done with the rr module, record_route() function.
To quote from iptel.org:
"[A] Mechanism by which a proxy can inform user agents that it wishes to stay
on the path of all further messages is called record routing. Such a proxy
would insert Record-Route header field into SIP messages which contain address
of the proxy. Messages sent within a dialog will then traverse all SIP proxies
that put a Record-Route header field into the message.
The recipient of the request receives a set of Record-Route header fields in
the message. It must mirror all the Record-Route header fields into responses
because the originator of the request also needs to know the set of proxies."
6 May
6 May
12:57 p.m.
Am Freitag, 3. Mai 2013, 16:33:23 schrieb Leo Brown:
So record-route goes like a stack and moves the
current contact one down the
chain.
You could then presumably truncate the list of other routes for privacy if
needed?
[..]
Hello,
Kamailio can't provide "real" SBC functionality, but you could use the topoh
module to mask e.g. the VIA headers.
Regards,
Henning Westerholt
3 May
3 May
6:54 p.m.
Hi Henning,
I added record_route() and now I see an extra record-route and Via: header:
.9........INVITE sip:44800800150@pstn-out.netfuse.net SIP/2.0
Record-Route: <sip:85.13.242.55;lr=on>
Via: SIP/2.0/UDP 85.13.242.55;branch=z9hG4bK388f.04bc8632.1
Via: SIP/2.0/UDP 81.88.163.210:5060;rport=5060;branch=z9hG4bK82ae6ced
INVITE sip:44800800150@our-pstn-switch SIP/2.0
Record-Route: <sip:mvno-edge;lr=on>
Via: SIP/2.0/UDP mvno-edge;branch=z9hG4bK388f.04bc8632.1
Via: SIP/2.0/UDP mvno-carrier:5060;rport=5060;branch=z9hG4bK82ae6ced
Contact: <sip:441234567890@mvno-carrier:5060>
I have replaced the relevant IP addresses in the example with mvno-edge, mvno-carrier, and
outbound-carrier. So the route got "recorded" but the Contact: still referenced
my mvno-carrier when inviting my outbound-carrier.
Accordingly, I do not get the BYE message from my originating mvno-carrier, after I send
them 200 OK they try to talk to my outbound-carrier.
Note this is how I am routing the call to my gateway:
# Change destination URI to our carrier
$ru = "sip:" + $rU + "@" +
$sel(cfg_get.gateways.outbound_carrier_1);
Any other ideas on how the Contact header should be modified?
Cheers
Leo
On 3 May 2013, at 16:29, Henning Westerholt <hw(a)kamailio.org> wrote:
if you want to ensure that your kamailio stays on the
path of the dialog for
following requests you probably want to use record-route headers for this.
This is usally done with the rr module, record_route() function.
6 May
6 May
2:20 p.m.
Am Freitag, 3. Mai 2013, 16:54:29 schrieb Leo Brown:
I added record_route() and now I see an extra
record-route and Via: header:
.9........INVITE sip:44800800150@pstn-out.netfuse.net SIP/2.0
Record-Route: <sip:85.13.242.55;lr=on>
Via: SIP/2.0/UDP 85.13.242.55;branch=z9hG4bK388f.04bc8632.1
Via: SIP/2.0/UDP 81.88.163.210:5060;rport=5060;branch=z9hG4bK82ae6ced
INVITE sip:44800800150@our-pstn-switch SIP/2.0
Record-Route: <sip:mvno-edge;lr=on>
Via: SIP/2.0/UDP mvno-edge;branch=z9hG4bK388f.04bc8632.1
Via: SIP/2.0/UDP mvno-carrier:5060;rport=5060;branch=z9hG4bK82ae6ced
Contact: <sip:441234567890@mvno-carrier:5060>
I have replaced the relevant IP addresses in the example with mvno-edge,
mvno-carrier, and outbound-carrier. So the route got "recorded" but the
Contact: still referenced my mvno-carrier when inviting my
outbound-carrier.
Accordingly, I do not get the BYE message from my originating mvno-carrier,
after I send them 200 OK they try to talk to my outbound-carrier.
Note this is how I am routing the call to my gateway:
# Change destination URI to our carrier
$ru = "sip:" + $rU + "@" +
$sel(cfg_get.gateways.outbound_carrier_1);
Any other ideas on how the Contact header should be modified?
Hi Leo,
maybe the originating gateway user agent is not configured correctly. Normally
one does not need to modify the Contact header for this functionality.
The originating user agent needs to "learn" the route set that he should
follow and specify then this the respective Route headers.
Take a look to this example on how it works in detail:
http://www.in2eps.com/fo-sip/tk-fo-sip-dialog.html
BTW, if your proxy on the path also needs to honour Route sets you need to use
also the loose_route function in rr module.
Henning Westerholt
7 May
7 May
6:24 p.m.
Hi Henning,
My inbound carrier has done some digging and discovered that the reason is they choose the
*first* address from the *last* Record-Route header.
Most gateways apparently add multiple Record-Route headers, whereas when we get a OK to
our INVITE from the carrier, the various Record-Route headers have been compiled into a
single Record-Route header like:
Record-Route: <sip:85.13.242.57;lr=on>
Record-Route: <sip:85.13.242.55;lr=on>
--> INVITE
Record-Route: <sip:8.13.22.57;lr=on>
Record-Route: <sip:8.13.22.55;lr=on>
<-- OK
Record-Route:
<sip:53.116.5.147;lr=on>,<sip:8.13.22.57;lr=on>,<sip:8.13.22.55;lr=on>
Is this normal behaviour of SIP, and either way is there any way to ask Kamailio to mangle
the 200 OK to split the Record-Route header into the separate entries that is possibly
more "standard"…?
Cheers,
Leo
On 6 May 2013, at 12:20, Henning Westerholt <hw(a)kamailio.org> wrote:
Am Freitag, 3. Mai 2013, 16:54:29 schrieb Leo Brown:
I added record_route() and now I see an extra
record-route and Via: header:
.9........INVITE sip:44800800150@pstn-out.netfuse.net SIP/2.0
Record-Route: <sip:85.13.242.55;lr=on>
Via: SIP/2.0/UDP 85.13.242.55;branch=z9hG4bK388f.04bc8632.1
Via: SIP/2.0/UDP 81.88.163.210:5060;rport=5060;branch=z9hG4bK82ae6ced
INVITE sip:44800800150@our-pstn-switch SIP/2.0
Record-Route: <sip:mvno-edge;lr=on>
Via: SIP/2.0/UDP mvno-edge;branch=z9hG4bK388f.04bc8632.1
Via: SIP/2.0/UDP mvno-carrier:5060;rport=5060;branch=z9hG4bK82ae6ced
Contact: <sip:441234567890@mvno-carrier:5060>
I have replaced the relevant IP addresses in the example with mvno-edge,
mvno-carrier, and outbound-carrier. So the route got "recorded" but the
Contact: still referenced my mvno-carrier when inviting my
outbound-carrier.
Accordingly, I do not get the BYE message from my originating mvno-carrier,
after I send them 200 OK they try to talk to my outbound-carrier.
Note this is how I am routing the call to my gateway:
# Change destination URI to our carrier
$ru = "sip:" + $rU + "@" +
$sel(cfg_get.gateways.outbound_carrier_1);
Any other ideas on how the Contact header should be modified?
Hi Leo,
maybe the originating gateway user agent is not configured correctly. Normally
one does not need to modify the Contact header for this functionality.
The originating user agent needs to "learn" the route set that he should
follow and specify then this the respective Route headers.
Take a look to this example on how it works in detail:
http://www.in2eps.com/fo-sip/tk-fo-sip-dialog.html
BTW, if your proxy on the path also needs to honour Route sets you need to use
also the loose_route function in rr module.
Henning Westerholt 
6:43 p.m.
Leo Brown writes:
Is this normal behaviour of SIP, and either way is
there any way to
ask Kamailio to mangle the 200 OK to split the Record-Route header
into the separate entries that is possibly more "standard"…?
route uris can be split into one or more r-r headers. sip UAs need to
be able to cope with both. one is not "more" standard than the other.
-- juha
4224
days inactive
4228
days old
7 comments
3 participants
participants (3)
-
Henning Westerholt -
Juha Heinanen -
Leo Brown