[SR-Users] Proxy Address
Dear All, I'm using kamailio as Proxy server for registration with RTP proxy as relay server for voice packets...I have an issue that when sending an Invite, the audio address in SDP (o header)is not RTP Proxy address while if I send another Invite to kamailio (second Invite), the RTP Proxy address will be present in SDP sent back by Kamailio... Anyone has a clue about what could be that matter? Regards ___ 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
Re: [SR-Users] Double tuple in notify
Yes, correct. I don't think this is anything to do with Kamailio, I will detach you from the thread, Thanks for all your assistance! Robert Jongbloed Vox Lucida Pty. Ltd. On 12/06/2011, at 8:11 PM, Iñaki Baz Castillo wrote: The id of both tuples are different so the server must keep both. However the client sholud use if-match header on the second PUBLISH to ensure it will replace the existing one. El 10/06/2011 21:32, Eugen Dedu eugen.d...@pu-pm.univ-fcomte.fr escribió: Hi again, Then it is the time for Eugen to add it in his sip client and send the patch for enhancing kamailio's presence server with rfc4481, as well :o) I start my application, and make my own status be shown. I change my status back and forth a few times between Away and DoNotDisturb (each time a publish is sent), the status returned (in notify) is good. When I change my status to Online/Available (and only to this), kamailio returns a double tuple. Is it normal to have a double tuple? If yes, which one to choose (the one with latest timestamp)? Here it is: NOTIFY sip:eugen.dedu@82.238.108.175:5060 SIP/2.0 CSeq: 7 NOTIFY Via: SIP/2.0/UDP 86.64.162.35;branch=z9hG4bK7634.4d863c14.0 User-Agent: Kamailio (1.5.3-notls (i386/linux)) From: sip:eugen.d...@ekiga.net;tag=f85b0bd16aaafa8479586ac9f88b3198-29fc Call-ID: 8a0d723b-0f8d-e011-84d7-0024d693d8e8@snoopy To: sip:eugen.d...@ekiga.net;tag=7c75723b-0f8d-e011-84d7-0024d693d8e8 Contact: sip:86.64.162.35:5060 Subscription-State: active;expires=270 Event: presence Content-Length: 938 Content-Type: application/pidf+xml Max-Forwards: 70 ?xml version=1.0 encoding=UTF-8? presence xmlns=urn:ietf:params:xml:ns:pidf xmlns:dm=urn:ietf:params:xml:ns:pidf:data-model xmlns: rpid=urn:ietf:params:xml:ns:pidf:rpid entity=pres:eugen.d...@ekiga.net tuple id=T0002 status basicopen/basic /status contact priority=1sip:eugen.d...@ekiga.net/contact noteonline - /note timestamp2011-06-04T13:55:56+02:00+02:00/timestamp /tuple tuple xmlns=urn:ietf:params:xml:ns:pidf id=T0001 status basicopen/basic /status contact priority=1sip:eugen.d...@ekiga.net/contact noteaway - jjk/note timestamp2011-06-04T13:54:37+02:00+02:00/timestamp /tuple dm:person xmlns:dm=urn:ietf:params:xml:ns:pidf:data-model xmlns:rpid=urn:ietf:params:xml:ns:pidf:rpid id=pid1 rpid:activities rpid:away/ /rpid:activities /dm:person /presence -- Eugen ___ 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 ___ 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
Re: [SR-Users] Proxy Address
What is the IP address if the first case? A wrong one or the original IP address provided by the caller? If it is the original IP address, either force_rtp_proxy was not called or there was a problem wiht the rtpproxy. Use xlog statements in front and after the rtpproxy functions and verify that rtpproxy is called. regards klaus On 13.06.2011 09:12, michel freiha wrote: Dear All, I'm using kamailio as Proxy server for registration with RTP proxy as relay server for voice packets...I have an issue that when sending an Invite, the audio address in SDP (o header)is not RTP Proxy address while if I send another Invite to kamailio (second Invite), the RTP Proxy address will be present in SDP sent back by Kamailio... Anyone has a clue about what could be that matter? Regards ___ 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 ___ 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
Re: [SR-Users] Kamailio dispatcher
Hello,
On 6/12/11 9:56 PM, Spinov Evgeniy wrote:
Hello.
DCM Hello,
DCM to understand the scenario:
DCM - first branch has destination uri ($du) set
Exactly.
DCM - it failed and gets to failure route where you call ds_next_domain()
DCM and $du s still the one from first branch?
Exactly. $du is being set by ds_select_dst() before t_relay() before
any branch in main loop. In failure route after ds_next_domain()
variable $du remains with old IP ( previous asterisk node ), while $rd
variable is updated.
is any particular reason to use ds_next_domain() after ds_select_dst()?
ds_next_domain() is the pair for ds_select_domain, in older versions it
happened that $du was reset automatically internally even by
ds_next_domain() due to execution of a core function which was no longer
needed in 3.1.
A quick solution if you need ds_select_dst() in combination with
ds_next_domain() is to call resetdsturi() in failure route. I will think
about and see if it is consistent to call it internally.
DCM What do you mean that not any of the nodes receive the packet ...?
Kamailio is standing before asterisks and relays packets to them. In
case, when there is no ds_next_domain() - packet is routed correctly
to the curtain node, defined by ds_select_dst(). While after
ds_next_domain() none of the 2 nodes receives the packet and call
terminates by the caller with Request timeout. Looks like t_relay()
sends packet somewhere to blackhole.
Can you look at sip trace with ngrep to see where they are sent?
Probably to the first destination that failed.
Cheers,
Daniel
Thank you.
DCM Cheers.
DCM Daniel
DCM On 6/10/11 6:43 PM, Evgeniy Spinov wrote:
Hello.
I had a Kamailio version of 3.0.3 and during this time configured a
failover with simple routine. In short like this:
if (ds_next_domain()) {
xlog(.);
if (!t_relay()) {
xlog(.);
return;
}
return;
} else {
t_reply(503);
}
Then I've updated to 3.1.3 and was happy enough until I've discovered
that my failover is not working anymore.
What is observed:
- It changes $rd variable, but not changing $du variable, is it ok?
- Not any of the nodes receive packet on t_relay after ds_next_domain().
- In route decision section, where t_on_reply() and t_on_failure() are
located I have the same t_relay() and it works fine, cause there is no
any ds_next_domains().
Is it a bug or I'm doing something wrong?
Thanks in advance.
___
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
--
Best regards,
Spinov Evgeniy. Intalisan. Development team.
Phone: +971 4 326-22-69 Skype: karator
Mobile: +971 55 774-04-87 ICQ:136613603
Website: www.intalisan.com
___
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
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
___
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
Re: [SR-Users] Proxy Address
Dear Sir, Can you please have a look to my config file and let me know please why the rtp proxy is not forced in SDP? PasteBin address: http://pastebin.com/NrJR8geQ Regards On Mon, Jun 13, 2011 at 10:49 AM, Klaus Darilion klaus.mailingli...@pernau.at wrote: What is the IP address if the first case? A wrong one or the original IP address provided by the caller? If it is the original IP address, either force_rtp_proxy was not called or there was a problem wiht the rtpproxy. Use xlog statements in front and after the rtpproxy functions and verify that rtpproxy is called. regards klaus On 13.06.2011 09:12, michel freiha wrote: Dear All, I'm using kamailio as Proxy server for registration with RTP proxy as relay server for voice packets...I have an issue that when sending an Invite, the audio address in SDP (o header)is not RTP Proxy address while if I send another Invite to kamailio (second Invite), the RTP Proxy address will be present in SDP sent back by Kamailio... Anyone has a clue about what could be that matter? Regards ___ 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 ___ 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 ___ 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
Re: [SR-Users] Kamailio dispatcher
On Mon, 2011-06-13 at 10:49 +0200, Daniel-Constantin Mierla wrote:
Hello,
On 6/12/11 9:56 PM, Spinov Evgeniy wrote:
Hello.
DCM Hello,
DCM to understand the scenario:
DCM - first branch has destination uri ($du) set
Exactly.
DCM - it failed and gets to failure route where you call ds_next_domain()
DCM and $du s still the one from first branch?
Exactly. $du is being set by ds_select_dst() before t_relay() before
any branch in main loop. In failure route after ds_next_domain()
variable $du remains with old IP ( previous asterisk node ), while $rd
variable is updated.
is any particular reason to use ds_next_domain() after ds_select_dst()?
ds_next_domain() is the pair for ds_select_domain, in older versions it
happened that $du was reset automatically internally even by
ds_next_domain() due to execution of a core function which was no longer
needed in 3.1.
I do not mind using ds_select_dst() however it seems to me, that in
following scenario it will give me a false result:
1. Call 1 is coming
2. Routed to GW 1
3. Call 2 is coming
4. Routed to GW 2
5. Call 1 timed out to GW 1 and call is going to failure route, where
ds_select_dst() is being called.
I guess ds_select_dst in this case will give GW 1 again in case of
round-robin fashion.
Also, there is no end of gateways, as ds_select_dst() will always return
one of the gateways, while when no gateways are alive - appropriate
reaction should happen.
That's why ds_next_domain() is more suitable, as performing all the
required actions without magic. Performed at least.
A quick solution if you need ds_select_dst() in combination with
ds_next_domain() is to call resetdsturi() in failure route. I will think
about and see if it is consistent to call it internally.
Works for me.
DCM What do you mean that not any of the nodes receive the packet ...?
Kamailio is standing before asterisks and relays packets to them. In
case, when there is no ds_next_domain() - packet is routed correctly
to the curtain node, defined by ds_select_dst(). While after
ds_next_domain() none of the 2 nodes receives the packet and call
terminates by the caller with Request timeout. Looks like t_relay()
sends packet somewhere to blackhole.
Can you look at sip trace with ngrep to see where they are sent?
Probably to the first destination that failed.
Yes. It sends packet to previous gateway, while in INVITE another IP
mentioned ( look at 1 and 2 strings ):
13:59:36.533705 IP KAMAILIO_IP.sip GW1_IP.sip: UDP, length 1020
EH..@.4..(...(.UINVITE sip:*44@GW2_IP:5060 SIP/2.0
Record-Route:
sip:KAMAILIO_IP;lr=on;ftag=ustdc;did=c4e.a81165f4;nat=yes
Via: SIP/2.0/UDP KAMAILIO_IP;branch=z9hG4bKccae.c54a1682.1
Max-Forwards: 69
To: sip:*44@KAMAILIO_IP
From: 2_101 sip:2_101@KAMAILIO_IP;tag=ustdc
Call-ID: yuwofwddoaqozwh@localhost.localdomain
CSeq: 527 INVITE
Contact: sip:2_101@UAC_PUBLIC_IP:5061
Content-Type: application/sdp
Allow:
INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.4.2
Content-Length: 330
Looks like a bug.
Cheers,
Daniel
Thank you.
DCM Cheers.
DCM Daniel
DCM On 6/10/11 6:43 PM, Evgeniy Spinov wrote:
Hello.
I had a Kamailio version of 3.0.3 and during this time configured a
failover with simple routine. In short like this:
if (ds_next_domain()) {
xlog(.);
if (!t_relay()) {
xlog(.);
return;
}
return;
} else {
t_reply(503);
}
Then I've updated to 3.1.3 and was happy enough until I've discovered
that my failover is not working anymore.
What is observed:
- It changes $rd variable, but not changing $du variable, is it ok?
- Not any of the nodes receive packet on t_relay after ds_next_domain().
- In route decision section, where t_on_reply() and t_on_failure() are
located I have the same t_relay() and it works fine, cause there is no
any ds_next_domains().
Is it a bug or I'm doing something wrong?
Thanks in advance.
___
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
___
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
___
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
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
Hello, On 6/11/11 9:24 AM, Iñaki Baz Castillo wrote: 2011/6/10 Iñaki Baz Castilloi...@aliax.net: Then if you use a simple config with t_relay(), go to tm module, see where t_relay() is defined, follow a bit the code and set a breakpoint by file and line number at a convenient location (as much as close to dns lookup functions if you can spot them in the code), so you don't do next/next/ too many times. Hi Daniel, I tryed to extract some useful data but got nothing. I've set breakpoints by indicating file:line of tm module as well as resolve.c file. The same using function names as breakpoints, etc. No result at all, I just get stuf about UDP, IO, read and so. Anyhow I've make some other tests and concluded that the issue is very simple: Kamailio performs NAPTR query but completely ignores its result. I've reported the bug in the tracker: http://sip-router.org/tracker/index.php?do=detailstask_id=135 I saw Andrei jumped in and added case insensitive comparison of naptr flags -- just to conclude this discussion, is it working on now? Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda ___ 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
Re: [SR-Users] Kamailio dispatcher
On 6/13/11 12:03 PM, Evgeniy Spinov wrote: On Mon, 2011-06-13 at 10:49 +0200, Daniel-Constantin Mierla wrote: Hello, On 6/12/11 9:56 PM, Spinov Evgeniy wrote: Hello. DCM Hello, DCM to understand the scenario: DCM - first branch has destination uri ($du) set Exactly. DCM - it failed and gets to failure route where you call ds_next_domain() DCM and $du s still the one from first branch? Exactly. $du is being set by ds_select_dst() before t_relay() before any branch in main loop. In failure route after ds_next_domain() variable $du remains with old IP ( previous asterisk node ), while $rd variable is updated. is any particular reason to use ds_next_domain() after ds_select_dst()? ds_next_domain() is the pair for ds_select_domain, in older versions it happened that $du was reset automatically internally even by ds_next_domain() due to execution of a core function which was no longer needed in 3.1. I do not mind using ds_select_dst() however it seems to me, that in following scenario it will give me a false result: 1. Call 1 is coming 2. Routed to GW 1 3. Call 2 is coming 4. Routed to GW 2 5. Call 1 timed out to GW 1 and call is going to failure route, where ds_select_dst() is being called. I guess ds_select_dst in this case will give GW 1 again in case of round-robin fashion. Also, there is no end of gateways, as ds_select_dst() will always return one of the gateways, while when no gateways are alive - appropriate reaction should happen. That's why ds_next_domain() is more suitable, as performing all the required actions without magic. Performed at least. ds_select_dst()/ds_next_dst() and ds_select_domain()/ds_next_domain() consume the already-tried destinations -- in any of the cases, none of gateways will be tried two times. ds_*_dst() sets $du and $ds_*_domain() sets $ru -- this is the difference between them. When you do first ds_select_dst() you set $du and when then you do $ds_next_domain() you set $ru -- if you would do $ds_next_dst() then $du will be set with the new gateway address. A quick solution if you need ds_select_dst() in combination with ds_next_domain() is to call resetdsturi() in failure route. I will think about and see if it is consistent to call it internally. Works for me. DCM What do you mean that not any of the nodes receive the packet ...? Kamailio is standing before asterisks and relays packets to them. In case, when there is no ds_next_domain() - packet is routed correctly to the curtain node, defined by ds_select_dst(). While after ds_next_domain() none of the 2 nodes receives the packet and call terminates by the caller with Request timeout. Looks like t_relay() sends packet somewhere to blackhole. Can you look at sip trace with ngrep to see where they are sent? Probably to the first destination that failed. Yes. It sends packet to previous gateway, while in INVITE another IP mentioned ( look at 1 and 2 strings ): 13:59:36.533705 IP KAMAILIO_IP.sip GW1_IP.sip: UDP, length 1020 EH..@.4..(...(.UINVITE sip:*44@GW2_IP:5060 SIP/2.0 Record-Route: sip:KAMAILIO_IP;lr=on;ftag=ustdc;did=c4e.a81165f4;nat=yes Via: SIP/2.0/UDP KAMAILIO_IP;branch=z9hG4bKccae.c54a1682.1 Max-Forwards: 69 To:sip:*44@KAMAILIO_IP From: 2_101sip:2_101@KAMAILIO_IP;tag=ustdc Call-ID: yuwofwddoaqozwh@localhost.localdomain CSeq: 527 INVITE Contact:sip:2_101@UAC_PUBLIC_IP:5061 Content-Type: application/sdp Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE Supported: replaces,norefersub,100rel User-Agent: Twinkle/1.4.2 Content-Length: 330 Looks like a bug. This is not a bug in sip routing as long as $du is set, then it is the field used for sip routing no matter you have in $ru -- $du is the internal outbound proxy address overwriting request-uri address. Maybe will be safe to introduce resetdsturi() in case of ds_next_domain() to be safe in combinations like ds_select_dst()+ds_next_domain(). Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda ___ 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
Re: [SR-Users] Meaning of empty body in NOTIFY
Hello, On 6/11/11 6:54 AM, Iñaki Baz Castillo wrote: 2011/6/10 Daniel-Constantin Mierlamico...@gmail.com: have you spotted in SIP/SIMPLE specs what has to be sent when the presentity is offline? My quick google was not that succesful. Maybe Inaki has the specs more fresh indexed in memory and can help. If the user has not published a offline presentity, then the server must not generate one. Sending an empty NOTIFY is the correct behaviour, which means unknown state (most of the subscribers should interpret it as offline). What is the purpose of publishing a presentity with offline status? Well, as most of the SIMPLE presence stuff, it's just a way to make things hyper-complex. There is however an exception: RFC 4827. The client goes on holidays for long time and decides to upload,, via *XCAP* a *permanent* (non expirable as a PUBLISH publication) pidf document in which it set the info it desires (maybe a status offline with a message I'm on holiday until June 20). right, it was the rfc i wanted to search for -- this features in kamailio presence implementation, can be controlled via module parameter pidf_manipulation , see: http://kamailio.org/docs/modules/stable/modules_k/presence_xml.html#id2940723 Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda ___ 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
Re: [SR-Users] Kamailio dispatcher
On Mon, 2011-06-13 at 12:12 +0200, Daniel-Constantin Mierla wrote: On 6/13/11 12:03 PM, Evgeniy Spinov wrote: On Mon, 2011-06-13 at 10:49 +0200, Daniel-Constantin Mierla wrote: Hello, On 6/12/11 9:56 PM, Spinov Evgeniy wrote: Hello. DCM Hello, DCM to understand the scenario: DCM - first branch has destination uri ($du) set Exactly. DCM - it failed and gets to failure route where you call ds_next_domain() DCM and $du s still the one from first branch? Exactly. $du is being set by ds_select_dst() before t_relay() before any branch in main loop. In failure route after ds_next_domain() variable $du remains with old IP ( previous asterisk node ), while $rd variable is updated. is any particular reason to use ds_next_domain() after ds_select_dst()? ds_next_domain() is the pair for ds_select_domain, in older versions it happened that $du was reset automatically internally even by ds_next_domain() due to execution of a core function which was no longer needed in 3.1. I do not mind using ds_select_dst() however it seems to me, that in following scenario it will give me a false result: 1. Call 1 is coming 2. Routed to GW 1 3. Call 2 is coming 4. Routed to GW 2 5. Call 1 timed out to GW 1 and call is going to failure route, where ds_select_dst() is being called. I guess ds_select_dst in this case will give GW 1 again in case of round-robin fashion. Also, there is no end of gateways, as ds_select_dst() will always return one of the gateways, while when no gateways are alive - appropriate reaction should happen. That's why ds_next_domain() is more suitable, as performing all the required actions without magic. Performed at least. ds_select_dst()/ds_next_dst() and ds_select_domain()/ds_next_domain() consume the already-tried destinations -- in any of the cases, none of gateways will be tried two times. ds_*_dst() sets $du and $ds_*_domain() sets $ru -- this is the difference between them. When you do first ds_select_dst() you set $du and when then you do $ds_next_domain() you set $ru -- if you would do $ds_next_dst() then $du will be set with the new gateway address. Changed to ds_next_dst() and it worked. The one thing, which confused me is that this was working before 3.1 in 3.0 version. Thanks for detailed explanation. Now I've got it. A quick solution if you need ds_select_dst() in combination with ds_next_domain() is to call resetdsturi() in failure route. I will think about and see if it is consistent to call it internally. Works for me. DCM What do you mean that not any of the nodes receive the packet ...? Kamailio is standing before asterisks and relays packets to them. In case, when there is no ds_next_domain() - packet is routed correctly to the curtain node, defined by ds_select_dst(). While after ds_next_domain() none of the 2 nodes receives the packet and call terminates by the caller with Request timeout. Looks like t_relay() sends packet somewhere to blackhole. Can you look at sip trace with ngrep to see where they are sent? Probably to the first destination that failed. Yes. It sends packet to previous gateway, while in INVITE another IP mentioned ( look at 1 and 2 strings ): 13:59:36.533705 IP KAMAILIO_IP.sip GW1_IP.sip: UDP, length 1020 EH..@.4..(...(.UINVITE sip:*44@GW2_IP:5060 SIP/2.0 Record-Route: sip:KAMAILIO_IP;lr=on;ftag=ustdc;did=c4e.a81165f4;nat=yes Via: SIP/2.0/UDP KAMAILIO_IP;branch=z9hG4bKccae.c54a1682.1 Max-Forwards: 69 To:sip:*44@KAMAILIO_IP From: 2_101sip:2_101@KAMAILIO_IP;tag=ustdc Call-ID: yuwofwddoaqozwh@localhost.localdomain CSeq: 527 INVITE Contact:sip:2_101@UAC_PUBLIC_IP:5061 Content-Type: application/sdp Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE Supported: replaces,norefersub,100rel User-Agent: Twinkle/1.4.2 Content-Length: 330 Looks like a bug. This is not a bug in sip routing as long as $du is set, then it is the field used for sip routing no matter you have in $ru -- $du is the internal outbound proxy address overwriting request-uri address. Maybe will be safe to introduce resetdsturi() in case of ds_next_domain() to be safe in combinations like ds_select_dst()+ds_next_domain(). I guess mention of this will be welcome in docs. Cause I've got my working example somewhere from Internet. I guess kamailio beginners may do the same and it will not work without any visible reason. Cheers, Daniel ___ 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
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
2011/6/13 Daniel-Constantin Mierla mico...@gmail.com: I saw Andrei jumped in and added case insensitive comparison of naptr flags -- just to conclude this discussion, is it working on now? Hi Daniel, I've tested it right *now* :) Yes, it works. -- Iñaki Baz Castillo i...@aliax.net ___ 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
[SR-Users] RTP proxy
Dear All,
I'm using the below config plan for routing my calls...The issue that
forcing rtp proxy is not working well and the rtp proxy is never
forcedCan you please provide me a guidance here?
if($rU=~^00.* )
{
if(!cr_route(default, domain.com, $rU, $rU,
call_id)){
sl_send_reply(403, Not allowed);
} else {
setbflag(6);
route(1);
}
exit; ## this was missing here -bogdan!!!
}
else
{
route(LOCATION);
route(RELAY);
}
}
# THIS IS THE GENERIC RELAY ROUTE THAT MUST BE USED ALL THE TIME
FOR RELAY
route[1]
{
# apply any NAT changes?
if(isflagset(5)||isbflagset(6)) {
route(4);
}
exit;
}
route[4]
{
if (is_method(BYE|CANCEL)) {
unforce_rtp_proxy();
} else if (is_method(INVITE)){
if (nat_uac_test(8)) {
*force_rtp_proxy();*
} else {
force_rtp_proxy();
}
xlog(L_ERR,6);
t_on_failure(1);
t_on_reply(1);
};
The call is going through Route[1] then through Route[4], but rtp proxy is
never forced...Any tips please?
Regards
___
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
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
On Jun 13, 2011, at 2:48 PM, Iñaki Baz Castillo i...@aliax.net wrote: 2011/6/13 Daniel-Constantin Mierla mico...@gmail.com: I saw Andrei jumped in and added case insensitive comparison of naptr flags -- just to conclude this discussion, is it working on now? Hi Daniel, I've tested it right *now* :) Yes, it works. Ok, thanks. Cheers, Daniel -- Iñaki Baz Castillo i...@aliax.net ___ 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
Re: [SR-Users] Multiple INVITEs and discarded call_control
It does not work, t_newtran always returns success, so it will never
absorb the retransmission.
So what I did was:
if ($sht(a=$ci::retrans) == 0) {
$sht(a=$ci::retrans) = 1;
} else {
exit();
}
xlog(L_INFO,XLOG: xxx);
call_control();
I prepared sipp scenario which generates 3 INVITEs separated by 200ms.
It will gives me this:
Jun 13 16:07:04 no-testing /sbin/kamailio[5274]: INFO: script: XLOG: xxx
Jun 13 16:07:04 no-testing /sbin/kamailio[5273]: WARNING: call_control
[call_control.c:1156]: dialog to trace controlled call was not
created. discarding callcontrol.
Jun 13 16:07:04 no-testing /sbin/kamailio[5275]: WARNING: call_control
[call_control.c:1156]: dialog to trace controlled call was not
created. discarding callcontrol.
So, the first INVITE was processed by call_control, another 2 were
not. But WHAT executed those two call_control is some kind of miracle
for me ... Callcontrol module is somehow executed at the beginning of
the config file where the values are set or why?
This is what I always set at the beginning:
modparam(dialog, dlg_flag, 4)
modparam(call_control, diverter_avp_id, 256)#used
to set billing party. default is From uri
modparam(call_control, canonical_uri_avp, $avp(s:can_uri))
On Mon, Jun 6, 2011 at 10:16 PM, Daniel-Constantin Mierla
mico...@gmail.com wrote:
Hello,
if it is a retransmission, then just do t_newtran() in your config file
before handling it to call control to be sure the retransmitted requests are
absorbed.
http://kamailio.org/docs/modules/stable/modules/tm.html#t_newtran
Cheers,
Daniel
On 6/6/11 4:29 PM, Mino Haluz wrote:
Hi,
my kamailio server is receiving from some customers 3 identical INVITEs when
call is initiated (separated by 200ms). Those 3 INVITEs are making a big
problem with call_control:
WARNING: call_control [call_control.c:1156]: dialog to trace controlled call
was not created. discarding callcontrol.
That is why, the prepaid limit is not working at all in this case. This way
the user can hack the prepaid protection of the account. Otherwise the
call_control is fuilly functional.
Anybody experienced the similar problem? If so, how to resolve it?
Thanks,
Mino Haluz
___
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
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
___
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
