Hi list, I am trying to make work to the parking of calls with openser and asterisk, which I want to do is when two UAC are in the middle of a call one of them can transfer a call with *700 and this is sent to asterisk to the extension by default...
the problem here is that when I make the transfer to the extension 700 the asterisk it doesn't return it to the extension that I originate the transfer, the call it returns to the extension in delay ..
I can see when I make the transfer in the SDP that the openser puts me c=IN IP4 0.0.0.0 , but asterisk doesn't return the call to the extension that I originate the transfer
U +2.857758 192.168.10.40:5060 -> 192.168.10.1:5060 INVITE sip:*700@192.168.10.1:5070 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.40:5060;branch=z9hG4bK1a7bc3cdf6e22598 Route: sip:192.168.10.1;lr=on;ftag=0d380f28344df9f2 From: "Ventas" sip:112@192.168.10.1;tag=0d380f28344df9f2 To: sip:*700@192.168.10.1;tag=as5aea7a9e Contact: sip:112@192.168.10.40:5060;transport=udp Supported: replaces, timer, path Referred-By: sip:120@192.168.10.38:5060 Proxy-Authorization: Digest username="112", realm="192.168.10.1", algorithm=MD5, uri="sip:*700@192.168.10.1:5070", nonce="495ac4ad695509e755aba895780497e8116e6353", response="40021b3138cbfefcd079505a55c6043f" Call-ID: f69f46f8461d45e0@192.168.10.40 CSeq: 55344 INVITE User-Agent: Grandstream GXP2020 1.1.6.16 Max-Forwards: 70 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE Content-Type: application/sdp Content-Length: 352
v=0 o=112 8001 8002 IN IP4 192.168.10.40 s=SIP Call c=IN IP4 0.0.0.0 t=0 0 m=audio 5006 RTP/AVP 0 18 3 97 2 9 101 a=sendonly a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:3 GSM/8000 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=20 a=rtpmap:2 G726-32/8000 a=rtpmap:9 G722/16000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11
# U +0.000646 192.168.10.1:5060 -> 192.168.10.40:5060 SIP/2.0 100 Giving a try Via: SIP/2.0/UDP 192.168.10.40:5060;branch=z9hG4bK1a7bc3cdf6e22598 From: "Ventas" sip:112@192.168.10.1;tag=0d380f28344df9f2 To: sip:*700@192.168.10.1;tag=as5aea7a9e Call-ID: f69f46f8461d45e0@192.168.10.40 CSeq: 55344 INVITE Server: OpenSER (1.3.4-notls (i386/linux)) Content-Length: 0
# U +0.000078 192.168.10.1:5060 -> 192.168.10.1:5070 INVITE sip:*700@192.168.10.1:5070 SIP/2.0 Record-Route: sip:192.168.10.1;lr=on;ftag=0d380f28344df9f2 Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK537.cbf8a716.0 Via: SIP/2.0/UDP 192.168.10.40:5060;branch=z9hG4bK1a7bc3cdf6e22598 From: "Ventas" sip:112@192.168.10.1;tag=0d380f28344df9f2 To: sip:*700@192.168.10.1;tag=as5aea7a9e Contact: sip:112@192.168.10.40:5060;transport=udp Supported: replaces, timer, path Referred-By: sip:120@192.168.10.38:5060 Proxy-Authorization: Digest username="112", realm="192.168.10.1", algorithm=MD5, uri="sip:*700@192.168.10.1:5070", nonce="495ac4ad695509e755aba895780497e8116e6353", response="40021b3138cbfefcd079505a55c6043f" Call-ID: f69f46f8461d45e0@192.168.10.40 CSeq: 55344 INVITE User-Agent: Grandstream GXP2020 1.1.6.16 Max-Forwards: 69 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE Content-Type: application/sdp Content-Length: 352
v=0 o=112 8001 8002 IN IP4 192.168.10.40 s=SIP Call c=IN IP4 0.0.0.0 t=0 0 m=audio 5006 RTP/AVP 0 18 3 97 2 9 101 a=sendonly a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:3 GSM/8000 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=20 a=rtpmap:2 G726-32/8000 a=rtpmap:9 G722/16000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11
# U +0.000263 192.168.10.1:5070 -> 192.168.10.1:5060 SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK537.cbf8a716.0;received=192.168.10.1 Via: SIP/2.0/UDP 192.168.10.40:5060;branch=z9hG4bK1a7bc3cdf6e22598 Record-Route: sip:192.168.10.1;lr=on;ftag=0d380f28344df9f2 From: "Ventas" sip:112@192.168.10.1;tag=0d380f28344df9f2 To: sip:*700@192.168.10.1;tag=as5aea7a9e Call-ID: f69f46f8461d45e0@192.168.10.40 CSeq: 55344 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: sip:*700@192.168.10.1:5070 Content-Length: 0
# U +0.000104 192.168.10.1:5070 -> 192.168.10.1:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK537.cbf8a716.0;received=192.168.10.1 Via: SIP/2.0/UDP 192.168.10.40:5060;branch=z9hG4bK1a7bc3cdf6e22598 Record-Route: sip:192.168.10.1;lr=on;ftag=0d380f28344df9f2 From: "Ventas" sip:112@192.168.10.1;tag=0d380f28344df9f2 To: sip:*700@192.168.10.1;tag=as5aea7a9e Call-ID: f69f46f8461d45e0@192.168.10.40 CSeq: 55344 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: sip:*700@192.168.10.1:5070 Content-Type: application/sdp Content-Length: 285
v=0 o=root 9758 9759 IN IP4 192.168.10.1 s=session c=IN IP4 192.168.10.1 t=0 0 m=audio 15948 RTP/AVP 0 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=recvonly
# U +0.000104 192.168.10.1:5060 -> 192.168.10.40:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.10.40:5060;branch=z9hG4bK1a7bc3cdf6e22598 Record-Route: sip:192.168.10.1;lr=on;ftag=0d380f28344df9f2 From: "Ventas" sip:112@192.168.10.1;tag=0d380f28344df9f2 To: sip:*700@192.168.10.1;tag=as5aea7a9e Call-ID: f69f46f8461d45e0@192.168.10.40 CSeq: 55344 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: sip:*700@192.168.10.1:5070 Content-Type: application/sdp Content-Length: 285
v=0 o=root 9758 9759 IN IP4 192.168.10.1 s=session c=IN IP4 192.168.10.1 t=0 0 m=audio 15948 RTP/AVP 0 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=recvonly
# U +0.054311 192.168.10.40:5060 -> 192.168.10.1:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK745a.fb2f15e.0 Via: SIP/2.0/UDP 192.168.10.1:5070;branch=z9hG4bK61abb915;rport=5070 Record-Route: sip:192.168.10.1;lr=on;ftag=as6fb8efad From: "Ventas" sip:112@192.168.10.1;tag=as6fb8efad To: sip:112@192.168.10.1;tag=368cbb40ae863e2a Call-ID: 3492c4a24c10596e6e3063c361c67eb9@192.168.10.1 CSeq: 102 INVITE User-Agent: Grandstream GXP2020 1.1.6.16 Contact: sip:112@192.168.10.40:5060;transport=udp Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE Content-Type: application/sdp Supported: replaces, timer Content-Length: 234
v=0 o=112 8000 8000 IN IP4 192.168.10.40 s=SIP Call c=IN IP4 192.168.10.40 t=0 0 m=audio 5004 RTP/AVP 0 101 a=sendrecv a=rtpmap:0 PCMU/8000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 m=video 0 RTP/AVP 99
# U +0.000097 192.168.10.1:5060 -> 192.168.10.1:5070 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.10.1:5070;branch=z9hG4bK61abb915;rport=5070 Record-Route: sip:192.168.10.1;lr=on;ftag=as6fb8efad From: "Ventas" sip:112@192.168.10.1;tag=as6fb8efad To: sip:112@192.168.10.1;tag=368cbb40ae863e2a Call-ID: 3492c4a24c10596e6e3063c361c67eb9@192.168.10.1 CSeq: 102 INVITE User-Agent: Grandstream GXP2020 1.1.6.16 Contact: sip:112@192.168.10.40:5060;transport=udp Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE Content-Type: application/sdp Supported: replaces, timer Content-Length: 234 I have openser and asterisk with realtime
any ideas ?
regards list
rickygm
El Miércoles, 31 de Diciembre de 2008, Ricky Gutierrez escribió:
Hi list, I am trying to make work to the parking of calls with openser and asterisk, which I want to do is when two UAC are in the middle of a call one of them can transfer a call with *700 and this is sent to asterisk to the extension by default...
the problem here is that when I make the transfer to the extension 700 the asterisk it doesn't return it to the extension that I originate the transfer, the call it returns to the extension in delay ..
I can see when I make the transfer in the SDP that the openser puts me c=IN IP4 0.0.0.0 , but asterisk doesn't return the call to the extension that I originate the transfer
Hi Ricky, this is more a quesiton about Asterisk than about Kamailio. Kamailio acts just as a proxy in your scenario and has nothing to handle about call parking.
Kamailio is pure SIP while your question is about a PBX feature. Sincerelly I don't see a solution/fix in the Kamailio side. Try the same scenario without Kamailio. When it works try it with Kamailio and compare the results. It could be, of course, a limitation/bugin Asterisk.