1 Dec
2009
1 Dec
'09
9:39 a.m.
Hi,
basically I'm using this structure at the moment:
SIP Users <----> Kamailio <-----> Asterisk <-----> PSTN
I have to add a diversion-functionality at kamailio-level, so to simply rewrite $ru with
something else defined in the database. That's working without problems. For billing
issues, I also have to add a Remote-Party-ID header, set to the SIP user, which initiated
the redirect in the database.
Now to the problem:
When a call is coming from PSTN, it's passing the asterisk server, then at kamailio
level $ru is rewritten and sent back to asterisk (I'm talking about a redirect to a
number in PSTN here)
What I've seen from the logs is, that asterisk is seeing that it gets an invite back
with the same call-id, and therefore it cancels the original invite and handles the whole
call internally via the Local Channel. The Problem is, that in the invite sent from
kamailio back to asterisk, I've set a Remote-Party-ID header to tell asterisk to set
the Callerid correctly for billing purposes. Now it seems that asterisk is _ignoring_ this
header from the second invite.
So is this an expected behavior ? If yes, how to do it correctly ?
Below you can see the verbose output of asterisk. Since the call is handled at
"Local" Channels the function to read sip headers does not work. The only
message I get is "thanks to SIP/tpsiptestproxyu01-00d0a0b8".
-- Called tpsiptestproxyu01/+435572949012
-- Now forwarding DAHDI/2-1 to 'Local/066480588134@from-internal' (thanks to
SIP/tpsiptestproxyu01-00d0a0b8)
-- Executing [066480588134@from-internal:1]
NoOp("Local/066480588134@from-internal-d69e;2", "435572501134") in new
stack
[Dec 1 15:14:50] WARNING[20506]: chan_sip.c:15797 func_header_read: This function can
only be used on SIP channels.
-- Executing [066480588134@from-internal:2]
NoOp("Local/066480588134@from-internal-d69e;2", "") in new stack
-- Executing [066480588134@from-internal:3]
Dial("Local/066480588134@from-internal-d69e;2",
"DAHDI/G0/066480588134") in new stack
-- Requested transfer capability: 0x00 - SPEECH
-- Called G0/066480588134
-- DAHDI/124-1 is proceeding passing it to Local/066480588134@from-internal-d69e;2
-- Local/066480588134@from-internal-d69e;1 is proceeding passing it to DAHDI/2-1
In the SIP debug you can see that asterisk is cancelling the dialog with kamailio and
doing it itself:
13:49:30.589054 IP [--ASTERISK--].5060 > [--KAMAILIO--].5060: SIP, length: 938
E.......@..L..,L..,N........INVITE sip:+435572949012@[--KAMAILIO--] SIP/2.0
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport
Max-Forwards: 70
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@[--KAMAILIO--]>
Contact: <sip:435572501134@[--ASTERISK--]>
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.6.1.5
Remote-Party-ID: "435572501134"
<sip:435572501134@[--ASTERISK--]>;privacy=off;screen=yes
Date: Tue, 01 Dec 2009 12:49:30 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 263
v=0
o=root 930830518 930830518 IN IP4 [--ASTERISK--]
s=Asterisk PBX 1.6.1.5
c=IN IP4 [--ASTERISK--]
t=0 0
m=audio 16924 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
13:49:30.591037 IP [--KAMAILIO--].5060 > [--ASTERISK--].5060: SIP, length: 342
E..r..@.@.[0..,N..,L.....^.aSIP/2.0 100 Trying
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport=5060
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@[--KAMAILIO--]>
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 INVITE
Server: OpenSER (1.3.2-notls (x86_64/linux))
Content-Length: 0
13:49:30.594345 IP [--KAMAILIO--].5060 > [--ASTERISK--].5060: SIP, length: 1093
E..a..@.@.XA..,N..,L.....M+LINVITE sip:066480588134@[--ASTERISK--]:5060;transport=udp
SIP/2.0
Record-Route: <sip:[--KAMAILIO--];lr;ftag=as27658014>
Via: SIP/2.0/UDP [--KAMAILIO--];branch=z9hG4bK06.05390227.0
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport=5060
Max-Forwards: 69
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@[--KAMAILIO--]>
Contact: <sip:435572501134@[--ASTERISK--]>
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.6.1.5
Date: Tue, 01 Dec 2009 12:49:30 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 263
Remote-Party-ID: "435572949012"
<sip:435572949012@tpseru01.tele.net>;party=caller;privacy=none;screen=yes
v=0
o=root 930830518 930830518 IN IP4 [--ASTERISK--]
s=Asterisk PBX 1.6.1.5
c=IN IP4 [--ASTERISK--]
t=0 0
m=audio 16924 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
13:49:30.594605 IP [--ASTERISK--].5060 > [--KAMAILIO--].5060: SIP, length: 460
E.......@..)..,L..,N....... CANCEL sip:+435572949012@[--KAMAILIO--] SIP/2.0
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport
Max-Forwards: 70
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@[--KAMAILIO--]>
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 CANCEL
User-Agent: Asterisk PBX 1.6.1.5
Remote-Party-ID: "435572501134"
<sip:435572501134@[--ASTERISK--]>;privacy=off;screen=yes
Content-Length: 0
13:49:30.596307 IP [--KAMAILIO--].5060 > [--ASTERISK--].5060: SIP, length: 387
E.....@.@.[...,N..,L.......KSIP/2.0 200 canceling
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport=5060
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@[--KAMAILIO--]>;tag=45db18648893e7acabf725621374d382-4ddb
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 CANCEL
Server: OpenSER (1.3.2-notls (x86_64/linux))
Content-Length: 0
13:49:30.596801 IP [--KAMAILIO--].5060 > [--ASTERISK--].5060: SIP, length: 396
E.....@.@.Z...,N..,L.......kSIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport=5060
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@[--KAMAILIO--]>;tag=45db18648893e7acabf725621374d382-4ddb
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 INVITE
Server: OpenSER (1.3.2-notls (x86_64/linux))
Content-Length: 0
13:49:30.596842 IP [--ASTERISK--].5060 > [--KAMAILIO--].5060: SIP, length: 539
E..7....@.....,L..,N.....#.oACK sip:+435572949012@[--KAMAILIO--] SIP/2.0
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport
Max-Forwards: 70
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@[--KAMAILIO--]>;tag=45db18648893e7acabf725621374d382-4ddb
Contact: <sip:435572501134@[--ASTERISK--]>
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 ACK
User-Agent: Asterisk PBX 1.6.1.5
Remote-Party-ID: "435572501134"
<sip:435572501134@[--ASTERISK--]>;privacy=off;screen=yes
Content-Length: 0
Thanks,
Florian
1 Dec
1 Dec
9:47 a.m.
Florian,
I had the same issue using Asterisk and Kamailio. Basically the problem is
that Asterisk interprets the call as a Loop (in the worst case) or might
continue resolving the call locally without taking care of the changes you
made in Kamaili.
I solved my issue using 3XX (redirect) messages.
Example:
sl_send_reply("301", "Go Here");
Try that on teh first place, then you can continue using Asterisk's dialplan
to change message details.
Cheers,
Uriel
On Tue, Dec 1, 2009 at 11:39 AM, Florian Meister <
Florian.Meister(a)teleport.vol.at> wrote:
Hi,
basically I'm using this structure at the moment:
SIP Users <----> Kamailio <-----> Asterisk <-----> PSTN
I have to add a diversion-functionality at kamailio-level, so to simply
rewrite $ru with something else defined in the database. That's working
without problems. For billing issues, I also have to add a Remote-Party-ID
header, set to the SIP user, which initiated the redirect in the database.
Now to the problem:
When a call is coming from PSTN, it's passing the asterisk server, then at
kamailio level $ru is rewritten and sent back to asterisk (I'm talking about
a redirect to a number in PSTN here)
What I've seen from the logs is, that asterisk is seeing that it gets an
invite back with the same call-id, and therefore it cancels the original
invite and handles the whole call internally via the Local Channel. The
Problem is, that in the invite sent from kamailio back to asterisk, I've set
a Remote-Party-ID header to tell asterisk to set the Callerid correctly for
billing purposes. Now it seems that asterisk is _ignoring_ this header from
the second invite.
So is this an expected behavior ? If yes, how to do it correctly ?
Below you can see the verbose output of asterisk. Since the call is handled
at "Local" Channels the function to read sip headers does not work. The only
message I get is "thanks to SIP/tpsiptestproxyu01-00d0a0b8".
-- Called tpsiptestproxyu01/+435572949012
-- Now forwarding DAHDI/2-1 to 'Local/066480588134@from-internal'
(thanks to SIP/tpsiptestproxyu01-00d0a0b8)
-- Executing [066480588134@from-internal:1]
NoOp("Local/066480588134@from-internal-d69e;2", "435572501134") in
new
stack
[Dec 1 15:14:50] WARNING[20506]: chan_sip.c:15797 func_header_read: This
function can only be used on SIP channels.
-- Executing [066480588134@from-internal:2]
NoOp("Local/066480588134@from-internal-d69e;2", "") in new stack
-- Executing [066480588134@from-internal:3]
Dial("Local/066480588134@from-internal-d69e;2",
"DAHDI/G0/066480588134")
in new stack
-- Requested transfer capability: 0x00 - SPEECH
-- Called G0/066480588134
-- DAHDI/124-1 is proceeding passing it to
Local/066480588134@from-internal-d69e;2
-- Local/066480588134@from-internal-d69e;1 is proceeding passing it to
DAHDI/2-1
In the SIP debug you can see that asterisk is cancelling the dialog with
kamailio and doing it itself:
13:49:30.589054 IP [--ASTERISK--].5060 > [--KAMAILIO--].5060: SIP, length:
938
E.......@..L..,L..,N........INVITE sip:+435572949012@[--KAMAILIO--]
SIP/2.0
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport
Max-Forwards: 70
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@[--KAMAILIO--]>
Contact: <sip:435572501134@[--ASTERISK--]>
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.6.1.5
Remote-Party-ID: "435572501134" <sip:435572501134@
[--ASTERISK--]>;privacy=off;screen=yes
Date: Tue, 01 Dec 2009 12:49:30 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 263
v=0
o=root 930830518 930830518 IN IP4 [--ASTERISK--]
s=Asterisk PBX 1.6.1.5
c=IN IP4 [--ASTERISK--]
t=0 0
m=audio 16924 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
13:49:30.591037 IP [--KAMAILIO--].5060 > [--ASTERISK--].5060: SIP, length:
342
E..r..@.@.[0..,N..,L.....^.aSIP/2.0 100 Trying
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport=5060
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@[--KAMAILIO--]>
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 INVITE
Server: OpenSER (1.3.2-notls (x86_64/linux))
Content-Length: 0
13:49:30.594345 IP [--KAMAILIO--].5060 > [--ASTERISK--].5060: SIP, length:
1093
E..a..@.@.XA..,N..,L.....M+LINVITE sip:066480588134@[--ASTERISK--]:5060;transport=udp
SIP/2.0
Record-Route: <sip:[--KAMAILIO--];lr;ftag=as27658014>
Via: SIP/2.0/UDP [--KAMAILIO--];branch=z9hG4bK06.05390227.0
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport=5060
Max-Forwards: 69
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@[--KAMAILIO--]>
Contact: <sip:435572501134@[--ASTERISK--]>
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.6.1.5
Date: Tue, 01 Dec 2009 12:49:30 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 263
Remote-Party-ID: "435572949012"
<sip:435572949012@tpseru01.tele.net<sip%3A435572949012@tpseru01.tele.net>
;party=caller;privacy=none;screen=yes
v=0
o=root 930830518 930830518 IN IP4 [--ASTERISK--]
s=Asterisk PBX 1.6.1.5
c=IN IP4 [--ASTERISK--]
t=0 0
m=audio 16924 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
13:49:30.594605 IP [--ASTERISK--].5060 > [--KAMAILIO--].5060: SIP, length:
460
E.......@..)..,L..,N....... CANCEL sip:+435572949012@[--KAMAILIO--]
SIP/2.0
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport
Max-Forwards: 70
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@[--KAMAILIO--]>
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 CANCEL
User-Agent: Asterisk PBX 1.6.1.5
Remote-Party-ID: "435572501134" <sip:435572501134@
[--ASTERISK--]>;privacy=off;screen=yes
Content-Length: 0
13:49:30.596307 IP [--KAMAILIO--].5060 > [--ASTERISK--].5060: SIP, length:
387
E.....@.@.[...,N..,L.......KSIP/2.0 200 canceling
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport=5060
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@
[--KAMAILIO--]>;tag=45db18648893e7acabf725621374d382-4ddb
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 CANCEL
Server: OpenSER (1.3.2-notls (x86_64/linux))
Content-Length: 0
13:49:30.596801 IP [--KAMAILIO--].5060 > [--ASTERISK--].5060: SIP, length:
396
E.....@.@.Z...,N..,L.......kSIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport=5060
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@
[--KAMAILIO--]>;tag=45db18648893e7acabf725621374d382-4ddb
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 INVITE
Server: OpenSER (1.3.2-notls (x86_64/linux))
Content-Length: 0
13:49:30.596842 IP [--ASTERISK--].5060 > [--KAMAILIO--].5060: SIP, length:
539
E..7....@.....,L..,N.....#.oACK sip:+435572949012@[--KAMAILIO--] SIP/2.0
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport
Max-Forwards: 70
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@
[--KAMAILIO--]>;tag=45db18648893e7acabf725621374d382-4ddb
Contact: <sip:435572501134@[--ASTERISK--]>
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 ACK
User-Agent: Asterisk PBX 1.6.1.5
Remote-Party-ID: "435572501134" <sip:435572501134@
[--ASTERISK--]>;privacy=off;screen=yes
Content-Length: 0
Thanks,
Florian
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
9:56 a.m.
New subject: [Kamailio-Users] Kamailio -> Asterisk Redirect/Reinvite and Remote-Party-ID
Hi Florian!
1. As Asterisk detects the "spiral" and handles it internally, there is
nothing you can do in Kamailio.
2. Just a warning: In general, Remote-Party-ID is used for CLI
indication, not for billing purposes. In your setup it might be possibly
to use RPID for billing to, but it would be better to use the proper
headers, like the obsolete (as you are using RPID I suspect you like
obsolete headers ;-) Diversion header, or the History-Info header.
(another warning: make sure that your system ignores/removes these
headers when sent by your customers - otherwise they can fool your
billing system and signal arbitrary CLIs)
3. You can for example easily bypass the problem by making the DB lookup
also in Asterisk. Use e.g. func_odbc to query your call-forwarding table
from within Asterisk, set the CDR(whatever) variables to fulfill you
billing requirements, and then send the call to the PSTN again.
regards
Klaus
Florian Meister wrote:
Hi,
basically I'm using this structure at the moment:
SIP Users <----> Kamailio <-----> Asterisk <-----> PSTN
I have to add a diversion-functionality at kamailio-level, so to simply rewrite $ru with
something else defined in the database. That's working without problems. For billing
issues, I also have to add a Remote-Party-ID header, set to the SIP user, which initiated
the redirect in the database.
Now to the problem:
When a call is coming from PSTN, it's passing the asterisk server, then at kamailio
level $ru is rewritten and sent back to asterisk (I'm talking about a redirect to a
number in PSTN here)
What I've seen from the logs is, that asterisk is seeing that it gets an invite back
with the same call-id, and therefore it cancels the original invite and handles the whole
call internally via the Local Channel. The Problem is, that in the invite sent from
kamailio back to asterisk, I've set a Remote-Party-ID header to tell asterisk to set
the Callerid correctly for billing purposes. Now it seems that asterisk is _ignoring_ this
header from the second invite.
So is this an expected behavior ? If yes, how to do it correctly ?
Below you can see the verbose output of asterisk. Since the call is handled at
"Local" Channels the function to read sip headers does not work. The only
message I get is "thanks to SIP/tpsiptestproxyu01-00d0a0b8".
-- Called tpsiptestproxyu01/+435572949012
-- Now forwarding DAHDI/2-1 to 'Local/066480588134@from-internal' (thanks to
SIP/tpsiptestproxyu01-00d0a0b8)
-- Executing [066480588134@from-internal:1]
NoOp("Local/066480588134@from-internal-d69e;2", "435572501134") in new
stack
[Dec 1 15:14:50] WARNING[20506]: chan_sip.c:15797 func_header_read: This function can
only be used on SIP channels.
-- Executing [066480588134@from-internal:2]
NoOp("Local/066480588134@from-internal-d69e;2", "") in new stack
-- Executing [066480588134@from-internal:3]
Dial("Local/066480588134@from-internal-d69e;2",
"DAHDI/G0/066480588134") in new stack
-- Requested transfer capability: 0x00 - SPEECH
-- Called G0/066480588134
-- DAHDI/124-1 is proceeding passing it to Local/066480588134@from-internal-d69e;2
-- Local/066480588134@from-internal-d69e;1 is proceeding passing it to DAHDI/2-1
In the SIP debug you can see that asterisk is cancelling the dialog with kamailio and
doing it itself:
13:49:30.589054 IP [--ASTERISK--].5060 > [--KAMAILIO--].5060: SIP, length: 938
E.......@..L..,L..,N........INVITE sip:+435572949012@[--KAMAILIO--] SIP/2.0
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport
Max-Forwards: 70
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@[--KAMAILIO--]>
Contact: <sip:435572501134@[--ASTERISK--]>
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.6.1.5
Remote-Party-ID: "435572501134"
<sip:435572501134@[--ASTERISK--]>;privacy=off;screen=yes
Date: Tue, 01 Dec 2009 12:49:30 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 263
v=0
o=root 930830518 930830518 IN IP4 [--ASTERISK--]
s=Asterisk PBX 1.6.1.5
c=IN IP4 [--ASTERISK--]
t=0 0
m=audio 16924 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
13:49:30.591037 IP [--KAMAILIO--].5060 > [--ASTERISK--].5060: SIP, length: 342
E..r..@.@.[0..,N..,L.....^.aSIP/2.0 100 Trying
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport=5060
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@[--KAMAILIO--]>
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 INVITE
Server: OpenSER (1.3.2-notls (x86_64/linux))
Content-Length: 0
13:49:30.594345 IP [--KAMAILIO--].5060 > [--ASTERISK--].5060: SIP, length: 1093
E..a..@.@.XA..,N..,L.....M+LINVITE sip:066480588134@[--ASTERISK--]:5060;transport=udp
SIP/2.0
Record-Route: <sip:[--KAMAILIO--];lr;ftag=as27658014>
Via: SIP/2.0/UDP [--KAMAILIO--];branch=z9hG4bK06.05390227.0
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport=5060
Max-Forwards: 69
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@[--KAMAILIO--]>
Contact: <sip:435572501134@[--ASTERISK--]>
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.6.1.5
Date: Tue, 01 Dec 2009 12:49:30 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 263
Remote-Party-ID: "435572949012"
<sip:435572949012@tpseru01.tele.net>;party=caller;privacy=none;screen=yes
v=0
o=root 930830518 930830518 IN IP4 [--ASTERISK--]
s=Asterisk PBX 1.6.1.5
c=IN IP4 [--ASTERISK--]
t=0 0
m=audio 16924 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
13:49:30.594605 IP [--ASTERISK--].5060 > [--KAMAILIO--].5060: SIP, length: 460
E.......@..)..,L..,N....... CANCEL sip:+435572949012@[--KAMAILIO--] SIP/2.0
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport
Max-Forwards: 70
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@[--KAMAILIO--]>
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 CANCEL
User-Agent: Asterisk PBX 1.6.1.5
Remote-Party-ID: "435572501134"
<sip:435572501134@[--ASTERISK--]>;privacy=off;screen=yes
Content-Length: 0
13:49:30.596307 IP [--KAMAILIO--].5060 > [--ASTERISK--].5060: SIP, length: 387
E.....@.@.[...,N..,L.......KSIP/2.0 200 canceling
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport=5060
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@[--KAMAILIO--]>;tag=45db18648893e7acabf725621374d382-4ddb
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 CANCEL
Server: OpenSER (1.3.2-notls (x86_64/linux))
Content-Length: 0
13:49:30.596801 IP [--KAMAILIO--].5060 > [--ASTERISK--].5060: SIP, length: 396
E.....@.@.Z...,N..,L.......kSIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport=5060
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@[--KAMAILIO--]>;tag=45db18648893e7acabf725621374d382-4ddb
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 INVITE
Server: OpenSER (1.3.2-notls (x86_64/linux))
Content-Length: 0
13:49:30.596842 IP [--ASTERISK--].5060 > [--KAMAILIO--].5060: SIP, length: 539
E..7....@.....,L..,N.....#.oACK sip:+435572949012@[--KAMAILIO--] SIP/2.0
Via: SIP/2.0/UDP [--ASTERISK--]:5060;branch=z9hG4bK5629d66b;rport
Max-Forwards: 70
From: "435572501134" <sip:435572501134@[--ASTERISK--]>;tag=as27658014
To: <sip:+435572949012@[--KAMAILIO--]>;tag=45db18648893e7acabf725621374d382-4ddb
Contact: <sip:435572501134@[--ASTERISK--]>
Call-ID: 4bbee84339a9e2d30850185317983625@[--ASTERISK--]
CSeq: 102 ACK
User-Agent: Asterisk PBX 1.6.1.5
Remote-Party-ID: "435572501134"
<sip:435572501134@[--ASTERISK--]>;privacy=off;screen=yes
Content-Length: 0
Thanks,
Florian
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
10:07 a.m.
New subject: [Kamailio-Users] Kamailio -> Asterisk Redirect/Reinvite and Remote-Party-ID
1. As Asterisk detects the "spiral" and
handles it internally, there is
nothing you can do in Kamailio.
That's bad. So I have to do the diversion check at two places ...
2. Just a warning: In general, Remote-Party-ID is used
for CLI
indication, not for billing purposes. In your setup it might be possibly
to use RPID for billing to, but it would be better to use the proper
headers, like the obsolete (as you are using RPID I suspect you like
obsolete headers ;-) Diversion header, or the History-Info header.
(another warning: make sure that your system ignores/removes these
headers when sent by your customers - otherwise they can fool your
billing system and signal arbitrary CLIs)
Thanks for the info. What are the headers which should be used for CLI, the not obsolete
ones ? ;-)
3. You can for example easily bypass the problem by
making the DB lookup
also in Asterisk. Use e.g. func_odbc to query your call-forwarding table
from within Asterisk, set the CDR(whatever) variables to fulfill you
billing requirements, and then send the call to the PSTN again.
Ok. That's what I have to do.
Thanks for your help,
Ciao, Florian
10:23 a.m.
New subject: [Kamailio-Users] Kamailio -> Asterisk Redirect/Reinvite and Remote-Party-ID
On Tuesday 01 December 2009 15:07:48 Florian Meister wrote:
Thanks for the info. What are the headers which should
be used for CLI, the
not obsolete ones ? ;-)
RFC 3323, 3324 and 3325
PAI: P-Asserted-Identity
PPI: P-Prefered-Identity
--
Raúl Alexis Betancor Santana
Dimensión Virtual
12:17 p.m.
New subject: [Kamailio-Users] domain alias support for multi domain configuration
Hi all,
I got table of subscribers attached to a domain "sip.domain.com". I wish
to support receiving "username(a)sip.antisip.com" as well as
"username(a)antisip.com".com".
I understand I could disable the check for domain in modules, but that
won't fit my needs as I have several separate domains. Is there any
possibility to define alias for one specific domain?
sip.domain.com alias of domain.com
sip.domain2.com alias of domain2.com
etc...
Tks,
Aymeric MOIZARD / ANTISIP
amsip - http://www.antisip.com
osip2 - http://www.osip.org
eXosip2 - http://savannah.nongnu.org/projects/exosip/
12:59 p.m.
New subject: [Kamailio-Users] domain alias support for multi domain configuration
El Martes, 1 de Diciembre de 2009, Aymeric Moizard escribió:
Hi all,
I got table of subscribers attached to a domain "sip.domain.com". I wish
to support receiving "username(a)sip.antisip.com" as well as
"username(a)antisip.com".com".
It sounds to DNS SRV usage with clients not supporting it so they need the DNS
A type.
If this is the case, I thin a better approach is setting the outbound proxy
for those clients (sip.antisip.com) and setting the user's domain to be
"antisip.com".
Don't try to use a multidomain environment with clients using domain aliases
as it makes impossible the authentication in the case the user uses
"user@domain" in the credentials username.
I understand I could disable the check for domain in
modules, but that
won't fit my needs as I have several separate domains. Is there any
possibility to define alias for one specific domain?
sip.domain.com alias of domain.com
sip.domain2.com alias of domain2.com
etc...
As I've said above, I think this is the wrong way.
Regards.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
2:43 p.m.
New subject: [Kamailio-Users] domain alias support for multi domain configuration
Hi Aymeric!
AFAIK there is no built-in feature in Kamailio 1.5 to solve this issue.
But maybe you can solve it manually - for each task separately:
- for call routing, just replace sip.domain with domain.com if detected,
e.g.: if ($rd=="sip.domain") { $rd="domain"; }
Also add sip.domain to domain table (if you use the domain module).
More complicated is authentication: I think it can be solved by checking
for "sip.domain" and putting "domain" into PV and use
pv_[www|proxy]_authorize() functions.
I think the hardest part is registration. I do not know a solution to
save() user(a)sip.domain as user@domain.
Probably the easiest solution would be - as indicated by Inaki -
ignoring clients which are wrong configured or do not allows to
configure outboundproxy and SIP domain separately.
Maybe it can be solved also by useng sip-router and ser's
userloc/registrar/auth module. AFAIK in ser's DB schema, the SIP AoR was
decoupled from the credentials (subscriber table) - but you would need
to migrate your DB schema.
regards
klaus
Aymeric Moizard wrote:
Hi all,
I got table of subscribers attached to a domain "sip.domain.com". I wish
to support receiving "username(a)sip.antisip.com" as well as
"username(a)antisip.com".com".
I understand I could disable the check for domain in modules, but that
won't fit my needs as I have several separate domains. Is there any
possibility to define alias for one specific domain?
sip.domain.com alias of domain.com
sip.domain2.com alias of domain2.com
etc...
Tks,
Aymeric MOIZARD / ANTISIP
amsip - http://www.antisip.com
osip2 - http://www.osip.org
eXosip2 - http://savannah.nongnu.org/projects/exosip/
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
12:55 p.m.
New subject: [Kamailio-Users] Kamailio -> Asterisk Redirect/Reinvite and Remote-Party-ID
Florian Meister wrote:
Thanks for the info. What are the headers which should
be used for CLI, the not obsolete ones ? ;-)
See Raul's email for the standardized headers. These are often used for
provider interconnect and also supported by recent PSTN gateways.
IIRC there is no explicit support for PAI, PPI in Asterisk, so you would
have to use the SIP_HEADER function and manually parse the headers.
So, as long as you use it only internally, you can use the obsolete RPID
header too, actually you could any header.
For example, internally (between proxies and Asterisk-Gateways) I use a
lot of proprietary headers for signaling for internal data, for example:
X-AU: +436991234567
(user provided CLI)
X-AN: +431234567
(network provided CLI)
X-C: +437201234567
(number which did the forwarding)
X-BID: 00046346
(billing ID (internal customer identity))
X-Hangupafter: 1000
(terminate call after x seconds)
regards
Klaus
2 Dec
2 Dec
4:05 a.m.
New subject: [Kamailio-Users] Kamailio -> Asterisk Redirect/Reinvite and Remote-Party-ID
Hi Klaus and Raul,
Thanks for your answers ... I think I'm more clear now.
ciao, flo
See Raul's email for the standardized headers.
These are often used for
provider interconnect and also supported by recent PSTN gateways.
IIRC there is no explicit support for PAI, PPI in Asterisk, so you would have to
use the SIP_HEADER function and manually parse the headers.
So, as long as you use it only internally, you can use the obsolete RPID header
too, actually you could any header.
5403
days inactive
5404
days old
9 comments
6 participants
participants (6)
-
Aymeric Moizard -
Florian Meister -
Iñaki Baz Castillo -
Klaus Darilion -
Raúl Alexis Betancor Santana -
Uriel Rozenbaum