Hello,
Does kamailio support PRACK method ?
If yes, how?
Thank you
Cordialement,
BERGANZ François
P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.
On Montag, 7. September 2009, BERGANZ François wrote:
Does kamailio support PRACK method ?
Hi François,
yes. Inaki already explained it nicely here:
http://www.kamailio.org/pipermail/users/2008-June/017695.html
Regards,
Henning
BERGANZ François wrote:
Does kamailio support PRACK method ?
If yes, how?
Well, of course it does. Kamailio supports any method, including any methods you yourself invent.
PRACKs are routed like any other non-INVITE request within a dialog. In other words, they should be covered by loose_route().
I'm seeing some *very* puzzling behavior from a bunch of our clients. Basically, the INVITE never makes it to the fone, it looks like the upstream router/modem just swallows it. The weird thing is, tweaking the username slightly resolves the issue, for a while at least. And then, it stops again. Anyone seen anything like this before? Any ideas? Am I missing something ridiculously obvious? Fwiw, I've seen this behavior in setups with *no* SIP ALG, and *no* firewall. That said, it really *does* look like a firewalling issue, doesnt it?
Here is a typical INVITE that is sent out from Kamailio. The username is mahesh.test204. The "fix" is to simply change the name to "mahesh.test205", or "mahesh.test20", or "ahesh.test204", etc. Is there something obviously wrong with the INVITE perhaps? Bad format?
INVITE sip:mahesh.test204@173.101.106.53:5060;rinstance=e2f54e94d29118d7;transport=UDP SIP/2.0. Record-Route: sip:74.217.82.147;lr;ftag=X8BN4N8vtXKej;nat=yes. Via: SIP/2.0/UDP 74.217.82.147;branch=z9hG4bK8e0c.0ded64d5.0. Via: SIP/2.0/UDP 74.217.82.232;received=74.217.82.232;rport=5060;branch=z9hG4bK3DtFg45Qetv9F. Max-Forwards: 69. From: "7732206484" sip:2065771035@74.217.82.232;tag=X8BN4N8vtXKej. To: sip:mahesh.test204@a5prodsbc.aptela.com. Call-ID: 67108c50-1f0d-122e-17b1-001a647938bc. CSeq: 382107 INVITE. Contact: sip:mod_sofia@74.217.82.232:5060. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: precondition, path, replaces. Allow-Events: talk, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 246. Subject: Local. Remote-Party-ID: "7732206484" sip:2065771035@74.217.82.147;party=calling;id-type=subscriber;screen=yes;privacy=off. . v=0. o=FreeSWITCH 1281422601 1281422602 IN IP4 74.217.82.232. s=FreeSWITCH. c=IN IP4 74.217.82.232. t=0 0. m=audio 13742 RTP/AVP 0 101 13. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=rtpmap:13 CN/8000. a=ptime:20.
Mahesh Paolini-Subramanya | CTO | mahesh@aptela.com | 703.386.1500 Ext. 9100 2250 Corporate Park Drive | Suite 150 | Herndon, VA | www.aptela.com Check out our Blog | Follow us on Twitter | Refer a Friend
Hello,
On 8/10/10 12:37 PM, Mahesh Paolini-Subramanya wrote:
I'm seeing some *very* puzzling behavior from a bunch of our clients. Basically, the INVITE never makes it to the fone, it looks like the upstream router/modem just swallows it. The weird thing is, tweaking the username slightly resolves the issue, for a while at least. And then, it stops again. Anyone seen anything like this before? Any ideas? Am I missing something ridiculously obvious? Fwiw, I've seen this behavior in setups with *no* SIP ALG, and *no* firewall. That said, it really *does* look like a firewalling issue, doesnt it?
if the request is sent by kamailio but not reaching the phone, then is something in the middle inspecting SIP and discarding (big brother?). Is it a particular type of phone, or any phone? At first sight, the request seems just fine. I cannot think of something else than alg/firewall in the middle, unless the phone itself discards it.
Cheers, Daniel
Here is a typical INVITE that is sent out from Kamailio. The username is /mahesh.test204/. The "fix" is to simply change the name to "mahesh.test205", or "mahesh.test20", or "ahesh.test204", etc. Is there something obviously wrong with the INVITE perhaps? Bad format?
INVITE sip:mahesh.test204@173.101.106.53:5060;rinstance=e2f54e94d29118d7;transport=UDP SIP/2.0. Record-Route: sip:74.217.82.147;lr;ftag=X8BN4N8vtXKej;nat=yes. Via: SIP/2.0/UDP 74.217.82.147;branch=z9hG4bK8e0c.0ded64d5.0. Via: SIP/2.0/UDP 74.217.82.232;received=74.217.82.232;rport=5060;branch=z9hG4bK3DtFg45Qetv9F. Max-Forwards: 69. From: "7732206484" sip:2065771035@74.217.82.232;tag=X8BN4N8vtXKej. To: sip:mahesh.test204@a5prodsbc.aptela.com. Call-ID: 67108c50-1f0d-122e-17b1-001a647938bc. CSeq: 382107 INVITE. Contact: sip:mod_sofia@74.217.82.232:5060. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: precondition, path, replaces. Allow-Events: talk, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 246. Subject: Local. Remote-Party-ID: "7732206484" sip:2065771035@74.217.82.147;party=calling;id-type=subscriber;screen=yes;privacy=off. . v=0. o=FreeSWITCH 1281422601 1281422602 IN IP4 74.217.82.232. s=FreeSWITCH. c=IN IP4 74.217.82.232. t=0 0. m=audio 13742 RTP/AVP 0 101 13. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=rtpmap:13 CN/8000. a=ptime:20.
Mahesh Paolini-Subramanya | CTO | mahesh@aptela.com mailto:mahesh@aptela.com | 703.386.1500 Ext. 9100 2250 Corporate Park Drive | Suite 150 | Herndon, VA | www.aptela.com http://www.aptela.com/ Check out our Blog http://www.aptela.com/blog | Follow us on Twitter http://twitter.com/Aptela | Refer a Friend http://www.aptela.com/referral
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Alex Balashov -
BERGANZ François -
Daniel-Constantin Mierla -
Henning Westerholt -
Mahesh Paolini-Subramanya