[SR-Users] Use of mtree module having multiple trees in the same table
hello, I wonder if anyone could help me understanding how can I use this module in a scenario where multiple mtrees are defined behind the same database table. I can't guess how to speficy to 'mt_match' the mtree I want to match against, since the 'mtree' module parameter defines a specific memory tree based on a specific table, but not based on a specific 'tname' value. Any help is apreciated, 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
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:
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
On Jun 13, 2011, at 2:48 PM, Iñaki Baz Castillo wrote: > 2011/6/13 Daniel-Constantin Mierla : >> 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 > ___ 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
2011/6/13 Daniel-Constantin Mierla : > 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 ___ 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: > > > > Via: SIP/2.0/UDP KAMAILIO_IP;branch=z9hG4bKccae.c54a1682.1 > > Max-Forwards: 69 > > To: > > From: "2_101";tag=ustdc > > Call-ID: yuwofwddoaqozwh@localhost.localdomain > > CSeq: 527 INVITE > > Contact: > > 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] Meaning of empty body in NOTIFY
Hello, On 6/11/11 6:54 AM, Iñaki Baz Castillo wrote: 2011/6/10 Daniel-Constantin Mierla: 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 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: Via: SIP/2.0/UDP KAMAILIO_IP;branch=z9hG4bKccae.c54a1682.1 Max-Forwards: 69 To: From: "2_101";tag=ustdc Call-ID: yuwofwddoaqozwh@localhost.localdomain CSeq: 527 INVITE Contact: 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] 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 Castillo: 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=details&task_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 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:
Via: SIP/2.0/UDP KAMAILIO_IP;branch=z9hG4bKccae.c54a1682.1
Max-Forwards: 69
To:
From: "2_101" ;tag=ustdc
Call-ID: yuwofwddoaqozwh@localhost.localdomain
CSeq: 527 INVITE
Contact:
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] 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
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
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] 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" 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: >> Subscription-State: active;expires=270 >> Event: presence >> Content-Length: 938 >> Content-Type: application/pidf+xml >> Max-Forwards: 70 >> >> >> > 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"> >> >> >> open >> >>sip:eugen.d...@ekiga.net >>online - >>2011-06-04T13:55:56+02:00+02:00 >> >> >> >> >> open >> >>sip:eugen.d...@ekiga.net >>away - jjk >>2011-06-04T13:54:37+02:00+02:00 >> >> > xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" id="pid1"> >> >> >> >> >> >> >> -- >> 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
[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
