[Users] provisional response management ( 100 Trying )

List overview All Threads
Download

newer

older

[Users] Re: [Devel] Please help...

Re: [Serusers] Multiple PSTN...

T.R. Missner

20 Jul 2006 20 Jul '06

4:31 p.m.

Attachments:

attachment.html (text/html — 3.2 KB)

Show replies by date

Klaus Darilion

20 Jul 20 Jul

7:39 p.m.

AFAI remember there was function t_relay_no_ack or similar. Take a lookat the README from TM module. regards klaus T.R. Missner wrote:

...

Hello, I want to send an immediate 100 trying message when an Invite is received, then I do a DB lookup, then I rewrite the RURI and forward the message using t_relay. Since I have already sent a 100 trying manually I’d like to short circuit the 100 t_relay sends so multiple 100 trying messages aren’t sent. Does anyone know of a way to do this? Thanks, T.R. ------------------------------------------------------------------------ _______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Norman Brandinger

7:45 p.m.

At the top of our ROUTE_INVITE, we have: #---------------------------------------------------------------------- # Let the UA know we are working on their request - # they shouldn't send retransmissions #---------------------------------------------------------------------- sl_send_reply("100", "Trying"); This seems to work and it was adapted from code used during REGISTER processing. Regards, Norm Klaus Darilion wrote:

...

AFAI remember there was function t_relay_no_ack or similar. Take a lookat the README from TM module. regards klaus T.R. Missner wrote:

_______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Weiter Leiter

8:31 p.m.

Hi, Norman Brandinger wrote:

...

If I got Missner's problem right, he wants to prevent sending multiple 100 replies back to the uac. The rfc says - Page 109, paragraph 5 - that "MUST be forwarded immediately [...] Any provisional response other than 100 (Trying)" and later, in same paragraph that "A stateful proxy MUST NOT immediately forward any other [= 101<=x<=299] responses". Now, it's true that in this case the proxy would not literally forward a 100 reply back, but the uac would still see 2x100. Now, if he does SL reply at the beginning, the tm module will, again, send a 100 on his own, before relaying. The question is how to prevent this, if I got it right... WL.

...

Regards, Norm Klaus Darilion wrote:

AFAI remember there was function t_relay_no_ack or similar. Take a lookat the README from TM module. regards klaus T.R. Missner wrote:

_______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

T.R. Missner

8:38 p.m.

...

At the top of our ROUTE_INVITE, we have: #--------------------------------------------------------------------- - # Let the UA know we are working on their request - # they shouldn't send retransmissions #--------------------------------------------------------------------- - sl_send_reply("100", "Trying"); This seems to work and it was adapted from code used during REGISTER processing.

...

>> the message using t_relay. >> >> Since I have already sent a 100 trying manually I'd like to short >> circuit the 100 t_relay sends so multiple 100 trying messages aren't

...

sent. Does anyone know of a way to do this? Thanks, T.R. -------------------------------------------------------------------- ---- _______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

_______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Evan Borgström

8:44 p.m.

Why would you want to prevent it? 1XX class messages are all provisional, do not solicit a response and are never forwarded upstream so only the previous hop will get multiple 100 messages which will effectively limit any chance of the upstream hop re-transmitting the original message. Take the following example; A user sends their initial INVITE, you sl_send_reply 100 and then check your proxy_authorize which returns a 407 and challenges the user. The user sends the second invite with credentials you sl_send_reply 100 and then check your proxy_authorize again and say, for instance, your DB server is now under heavy load (a cronjob runs, etc) and takes longer then 1s to respond, since you haven't called t_relay yet which generates the second 100 message your initial 100 message would still stop the user from re-transmitting the INVITE while proxy_authorize is waiting for the DB. -Evan T.R. Missner wrote:

...

At the top of our ROUTE_INVITE, we have: #--------------------------------------------------------------------- - # Let the UA know we are working on their request - # they shouldn't send retransmissions #--------------------------------------------------------------------- - sl_send_reply("100", "Trying"); This seems to work and it was adapted from code used during REGISTER processing.

>> the message using t_relay. >> >> Since I have already sent a 100 trying manually I'd like to short >> circuit the 100 t_relay sends so multiple 100 trying messages aren't

_______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

_______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Weiter Leiter

9:14 p.m.

Hi, Evan Borgström wrote:

...

-Evan T.R. Missner wrote:

At the top of our ROUTE_INVITE, we have: #--------------------------------------------------------------------- - # Let the UA know we are working on their request - # they shouldn't send retransmissions #--------------------------------------------------------------------- - sl_send_reply("100", "Trying"); This seems to work and it was adapted from code used during REGISTER processing.

Regards, Norm Klaus Darilion wrote:

AFAI remember there was function t_relay_no_ack or similar. Take a lookat the README from TM module. regards klaus T.R. Missner wrote: > Hello, > > > > I want to send an immediate 100 trying message when an Invite is > received, then I do a DB lookup, then I rewrite the RURI and forward > > the message using t_relay. > > Since I have already sent a 100 trying manually I'd like to short > circuit the 100 t_relay sends so multiple 100 trying messages aren't > > sent. > > Does anyone know of a way to do this? > > > > Thanks, > > > > T.R. > > > > > -------------------------------------------------------------------- > ---- > > > _______________________________________________ > Users mailing list > Users(a)openser.org > http://openser.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

_______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Evan Borgström

9:25 p.m.

Well, if we're going get technical about conforming to the RFC then sending a 100 message for anything other than an INVITE is a "SHOULD NOT". 8.2.6.1 Sending a Provisional Response One largely non-method-specific guideline for the generation of responses is that UASs SHOULD NOT issue a provisional response for a non-INVITE request. Rather, UASs SHOULD generate a final response to a non-INVITE request as soon as possible. However, to be RFC strict multiple responses to INVITE's are indeed allowed. Check section 13.1 Before sending a final response, the UAS can also send provisional responses (1xx) to advise the UAC of progress in contacting the called user. After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response. All of my real world practices show that sending provisional messages for non INVITE messages is a big help, especially when you get into presence and IM related stuff. All too often clients like eyeBeam re-transmit SUBSCRIBE's, PUBLISH's and MESSAGE's because of latency within the network if you don't send a 100 trying upon receipt. So for me even if it's a SHOULD NOT it still makes my life easier than dealing with questions about receiving IM's twice... -Evan Weiter Leiter wrote:

...

Hi, Evan Borgström wrote:

-Evan T.R. Missner wrote:

At the top of our ROUTE_INVITE, we have: #--------------------------------------------------------------------- - # Let the UA know we are working on their request - # they shouldn't send retransmissions #--------------------------------------------------------------------- - sl_send_reply("100", "Trying"); This seems to work and it was adapted from code used during REGISTER processing.

Regards, Norm Klaus Darilion wrote: > AFAI remember there was function t_relay_no_ack or similar. Take a > lookat the README from TM module. > > regards > klaus > > T.R. Missner wrote: > >> Hello, >> >> >> >> I want to send an immediate 100 trying message when an Invite is >> received, then I do a DB lookup, then I rewrite the RURI and forward >> >> the message using t_relay. >> >> Since I have already sent a 100 trying manually I'd like to short >> circuit the 100 t_relay sends so multiple 100 trying messages aren't >> >> sent. >> >> Does anyone know of a way to do this? >> >> >> >> Thanks, >> >> >> >> T.R. >> >> >> >> >> -------------------------------------------------------------------- >> ---- >> >> >> _______________________________________________ >> Users mailing list >> Users(a)openser.org >> http://openser.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > Users(a)openser.org > http://openser.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

_______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Klaus Darilion

10:22 p.m.

On Thu, July 20, 2006 20:25, Evan Borgström said:

...

Well, if we're going get technical about conforming to the RFC then sending a 100 message for anything other than an INVITE is a "SHOULD NOT".

AFAIK somewhere in the RFC they say you should send a provisional response if the processing of the requests (till we can send a final response) will take more the 200 ms. Thus, sending 100 for non-INVITE is IMO fine. Especially for REGISTER which is handled stateless in openser. regards klaus PS: If you still want to know how to do it without 2x100: Use t_newtran and t_forward_nonack. http://www.openser.org/docs/modules/1.1.x/tm.html#TFORWARDNONACK

...

8.2.6.1 Sending a Provisional Response One largely non-method-specific guideline for the generation of responses is that UASs SHOULD NOT issue a provisional response for a non-INVITE request. Rather, UASs SHOULD generate a final response to a non-INVITE request as soon as possible. However, to be RFC strict multiple responses to INVITE's are indeed allowed. Check section 13.1 Before sending a final response, the UAS can also send provisional responses (1xx) to advise the UAC of progress in contacting the called user. After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response. All of my real world practices show that sending provisional messages for non INVITE messages is a big help, especially when you get into presence and IM related stuff. All too often clients like eyeBeam re-transmit SUBSCRIBE's, PUBLISH's and MESSAGE's because of latency within the network if you don't send a 100 trying upon receipt. So for me even if it's a SHOULD NOT it still makes my life easier than dealing with questions about receiving IM's twice... -Evan Weiter Leiter wrote:

Hi, Evan Borgström wrote:

-Evan T.R. Missner wrote:

You have the question exactly correct Now - how can I do this? -----Original Message----- From: users-bounces(a)openser.org [mailto:users-bounces@openser.org] On Behalf Of Weiter Leiter Sent: Thursday, July 20, 2006 1:31 PM To: Norman Brandinger Cc: users Subject: Re: [Users] provisional response management ( 100 Trying ) Hi, Norman Brandinger wrote: > At the top of our ROUTE_INVITE, we have: > > > #--------------------------------------------------------------------- > - # Let the UA know we are working on their request - # they > shouldn't send retransmissions > > #--------------------------------------------------------------------- > - > sl_send_reply("100", "Trying"); > > This seems to work and it was adapted from code used during REGISTER > processing. > If I got Missner's problem right, he wants to prevent sending multiple 100 replies back to the uac. The rfc says - Page 109, paragraph 5 - that "MUST be forwarded immediately [...] Any provisional response other than 100 (Trying)" and later, in same paragraph that "A stateful proxy MUST NOT immediately forward any other [= 101<=x<=299] responses". Now, it's true that in this case the proxy would not literally forward a 100 reply back, but the uac would still see 2x100. Now, if he does SL reply at the beginning, the tm module will, again, send a 100 on his own, before relaying. The question is how to prevent this, if I got it right... WL. > Regards, > Norm > > Klaus Darilion wrote: > >> AFAI remember there was function t_relay_no_ack or similar. Take a >> lookat the README from TM module. >> >> regards >> klaus >> >> T.R. Missner wrote: >> >>> Hello, >>> >>> >>> >>> I want to send an immediate 100 trying message when an Invite is >>> received, then I do a DB lookup, then I rewrite the RURI and >>> forward >>> >>> the message using t_relay. >>> >>> Since I have already sent a 100 trying manually I'd like to short >>> circuit the 100 t_relay sends so multiple 100 trying messages >>> aren't >>> >>> sent. >>> >>> Does anyone know of a way to do this? >>> >>> >>> >>> Thanks, >>> >>> >>> >>> T.R. >>> >>> >>> >>> >>> -------------------------------------------------------------------- >>> ---- >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)openser.org >>> http://openser.org/cgi-bin/mailman/listinfo/users >>> >> _______________________________________________ >> Users mailing list >> Users(a)openser.org >> http://openser.org/cgi-bin/mailman/listinfo/users >> >> >> >> > _______________________________________________ > Users mailing list > Users(a)openser.org > http://openser.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

_______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Evan Borgström

10:34 p.m.

Yep, section 21.1 says that. It's a perfect example of the grey area the RFC creates and why most of us send provisional responses for most/all messages. :) Just remember that if you're going to sl_send_reply with a 100 for all messages you should first check that method != ACK as ACK's MUST NOT generate a provisional message. -Evan Klaus Darilion wrote:

...

On Thu, July 20, 2006 20:25, Evan Borgström said:

Well, if we're going get technical about conforming to the RFC then sending a 100 message for anything other than an INVITE is a "SHOULD NOT".

Hi, Evan Borgström wrote:

The question is not whether sl replying is good or not - it for sure is. The question is how to be 100% conformant. However, imho, this misalignment is completely negligible, as if you make abstraction of the possible different reason phrase, the two messages will be identical - this duplicating can be done by some lower layered network entity, so, from the uac's point of view, the 2 100s should not be a problem. However, adding a config for tm not to take care of the 100 might be the cherry on the cake. WL. ps. Imo, this is one of ser/openser's problems: one script function can actually take some more (more or less documented) "atomic" actions than its name states (even in cases where otherwise could be done, without a performance or complexity impact), which, from a strictly programming point of view is completely wrong. > -Evan > > T.R. Missner wrote: > >> You have the question exactly correct >> >> Now - how can I do this? >> >> -----Original Message----- >> From: users-bounces(a)openser.org [mailto:users-bounces@openser.org] On >> Behalf Of Weiter Leiter >> Sent: Thursday, July 20, 2006 1:31 PM >> To: Norman Brandinger >> Cc: users >> Subject: Re: [Users] provisional response management ( 100 Trying ) >> >> Hi, >> >> Norman Brandinger wrote: >> >>> At the top of our ROUTE_INVITE, we have: >>> >>> >>> #--------------------------------------------------------------------- >>> - # Let the UA know we are working on their request - # they >>> shouldn't send retransmissions >>> >>> #--------------------------------------------------------------------- >>> - >>> sl_send_reply("100", "Trying"); >>> >>> This seems to work and it was adapted from code used during REGISTER >>> processing. >>> >> If I got Missner's problem right, he wants to prevent sending multiple >> 100 replies back to the uac. >> >> The rfc says - Page 109, paragraph 5 - that "MUST be forwarded >> immediately [...] Any provisional response other than 100 (Trying)" >> and >> later, in same paragraph that "A stateful proxy MUST NOT immediately >> forward any other [= 101<=x<=299] responses". Now, it's true that in >> this case the proxy would not literally forward a 100 reply back, but >> the uac would still see 2x100. >> >> Now, if he does SL reply at the beginning, the tm module will, again, >> send a 100 on his own, before relaying. >> >> The question is how to prevent this, if I got it right... >> >> >> WL. >> >> >>> Regards, >>> Norm >>> >>> Klaus Darilion wrote: >>> >>>> AFAI remember there was function t_relay_no_ack or similar. Take a >>>> lookat the README from TM module. >>>> >>>> regards >>>> klaus >>>> >>>> T.R. Missner wrote: >>>> >>>>> Hello, >>>>> >>>>> >>>>> >>>>> I want to send an immediate 100 trying message when an Invite is >>>>> received, then I do a DB lookup, then I rewrite the RURI and >>>>> forward >>>>> >>>>> the message using t_relay. >>>>> >>>>> Since I have already sent a 100 trying manually I'd like to short >>>>> circuit the 100 t_relay sends so multiple 100 trying messages >>>>> aren't >>>>> >>>>> sent. >>>>> >>>>> Does anyone know of a way to do this? >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> >>>>> T.R. >>>>> >>>>> >>>>> >>>>> >>>>> -------------------------------------------------------------------- >>>>> ---- >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users(a)openser.org >>>>> http://openser.org/cgi-bin/mailman/listinfo/users >>>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)openser.org >>>> http://openser.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)openser.org >>> http://openser.org/cgi-bin/mailman/listinfo/users >>> >>> >> _______________________________________________ >> Users mailing list >> Users(a)openser.org >> http://openser.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> Users(a)openser.org >> http://openser.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > Users(a)openser.org > http://openser.org/cgi-bin/mailman/listinfo/users > >

_______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

samuel

21 Jul 21 Jul

10:30 a.m.

Being normative, there's also an RFC relating to the provisional replies to non-INVITE transactions, RFC 4320, which does allow sending 100 provisional responses, and even recommend it, under some circumstances. Just my 2 cents. Samuel. 2006/7/20, Evan Borgström <evan.borgstrom(a)ca.mci.com>om>:

...

On Thu, July 20, 2006 20:25, Evan Borgström said: > Well, if we're going get technical about conforming to the RFC

then

> sending a 100 message for anything other than an INVITE is a "SHOULD

NOT".

AFAIK somewhere in the RFC they say you should send a provisional

response

if the processing of the requests (till we can send a final response)

will

take more the 200 ms. Thus, sending 100 for non-INVITE is IMO fine. Especially for REGISTER which is handled stateless in openser. regards klaus PS: If you still want to know how to do it without 2x100: Use t_newtran and t_forward_nonack. http://www.openser.org/docs/modules/1.1.x/tm.html#TFORWARDNONACK > 8.2.6.1 Sending a Provisional Response > > One largely non-method-specific guideline for the generation of > responses is that UASs SHOULD NOT issue a provisional response for a > non-INVITE request. Rather, UASs SHOULD generate a final response

> a non-INVITE request as soon as possible. > > > However, to be RFC strict multiple responses to INVITE's are

indeed

> allowed. Check section 13.1 > > > Before sending a final response, the UAS can also send provisional > responses (1xx) to advise the UAC of progress in contacting the > called user. > > After possibly receiving one or more provisional responses, the UAC > will get one or more 2xx responses or one non-2xx final response. > > > All of my real world practices show that sending provisional

messages

> for non INVITE messages is a big help, especially when you get into > presence and IM related stuff. All too often clients like eyeBeam > re-transmit SUBSCRIBE's, PUBLISH's and MESSAGE's because of latency > within the network if you don't send a 100 trying upon receipt. So for > me even if it's a SHOULD NOT it still makes my life easier than dealing > with questions about receiving IM's twice... > > -Evan > > Weiter Leiter wrote: >> Hi, >> >> Evan Borgström wrote: >>> Why would you want to prevent it? 1XX class messages are all >>> provisional, do not solicit a response and are never forwarded

upstream

>>> so only the previous hop will get multiple 100 messages which will >>> effectively limit any chance of the upstream hop re-transmitting the >>> original message. >>> >>> Take the following example; A user sends their initial INVITE, you >>> sl_send_reply 100 and then check your proxy_authorize which returns a >>> 407 and challenges the user. The user sends the second invite with >>> credentials you sl_send_reply 100 and then check your proxy_authorize >>> again and say, for instance, your DB server is now under heavy load

>>> cronjob runs, etc) and takes longer then 1s to respond, since you >>> haven't called t_relay yet which generates the second 100 message

your

>>> initial 100 message would still stop the user from re-transmitting

the

>>> INVITE while proxy_authorize is waiting for the DB. >>> >> The question is not whether sl replying is good or not - it for sure

is.

>> The question is how to be 100% conformant. >> >> However, imho, this misalignment is completely negligible, as if you >> make abstraction of the possible different reason phrase, the two >> messages will be identical - this duplicating can be done by some

lower

>> layered network entity, so, from the uac's point of view, the 2 100s >> should not be a problem. >> >> However, adding a config for tm not to take care of the 100 might be

the

>> cherry on the cake. >> >> WL. >> >> ps. Imo, this is one of ser/openser's problems: one script function

can

>> actually take some more (more or less documented) "atomic" actions

than

>> its name states (even in cases where otherwise could be done, without

>> performance or complexity impact), which, from a strictly programming >> point of view is completely wrong. >> >>> -Evan >>> >>> T.R. Missner wrote: >>> >>>> You have the question exactly correct >>>> >>>> Now - how can I do this? >>>> >>>> -----Original Message----- >>>> From: users-bounces(a)openser.org [mailto:users-bounces@openser.org]

>>>> Behalf Of Weiter Leiter >>>> Sent: Thursday, July 20, 2006 1:31 PM >>>> To: Norman Brandinger >>>> Cc: users >>>> Subject: Re: [Users] provisional response management ( 100 Trying ) >>>> >>>> Hi, >>>> >>>> Norman Brandinger wrote: >>>> >>>>> At the top of our ROUTE_INVITE, we have: >>>>> >>>>> >>>>>

#---------------------------------------------------------------------

>>>>> - # Let the UA know we are working on their request - # they >>>>> shouldn't send retransmissions >>>>> >>>>>

#---------------------------------------------------------------------

>>>>> - >>>>> sl_send_reply("100", "Trying"); >>>>> >>>>> This seems to work and it was adapted from code used during

>>>>> processing. >>>>> >>>> If I got Missner's problem right, he wants to prevent sending

multiple

>>>> 100 replies back to the uac. >>>> >>>> The rfc says - Page 109, paragraph 5 - that "MUST be forwarded >>>> immediately [...] Any provisional response other than 100 (Trying)" >>>> and >>>> later, in same paragraph that "A stateful proxy MUST NOT immediately >>>> forward any other [= 101<=x<=299] responses". Now, it's true that

>>>> this case the proxy would not literally forward a 100 reply back,

but

>>>> the uac would still see 2x100. >>>> >>>> Now, if he does SL reply at the beginning, the tm module will,

again,

>>>> send a 100 on his own, before relaying. >>>> >>>> The question is how to prevent this, if I got it right... >>>> >>>> >>>> WL. >>>> >>>> >>>>> Regards, >>>>> Norm >>>>> >>>>> Klaus Darilion wrote: >>>>> >>>>>> AFAI remember there was function t_relay_no_ack or similar. Take a >>>>>> lookat the README from TM module. >>>>>> >>>>>> regards >>>>>> klaus >>>>>> >>>>>> T.R. Missner wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I want to send an immediate 100 trying message when an Invite is >>>>>>> received, then I do a DB lookup, then I rewrite the RURI and >>>>>>> forward >>>>>>> >>>>>>> the message using t_relay. >>>>>>> >>>>>>> Since I have already sent a 100 trying manually I'd like to short >>>>>>> circuit the 100 t_relay sends so multiple 100 trying messages >>>>>>> aren't >>>>>>> >>>>>>> sent. >>>>>>> >>>>>>> Does anyone know of a way to do this? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> >>>>>>> >>>>>>> T.R. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>

--------------------------------------------------------------------

>>>>> ---- >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users(a)openser.org >>>>> http://openser.org/cgi-bin/mailman/listinfo/users >>>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)openser.org >>>> http://openser.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)openser.org >>> http://openser.org/cgi-bin/mailman/listinfo/users >>> >>> >> _______________________________________________ >> Users mailing list >> Users(a)openser.org >> http://openser.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> Users(a)openser.org >> http://openser.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > Users(a)openser.org > http://openser.org/cgi-bin/mailman/listinfo/users > >

_______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

6703

days inactive

6704

days old

sr-users@lists.kamailio.org

Manage subscription

10 comments

6 participants

tags (0)

participants (6)

Evan Borgström
Klaus Darilion
Norman Brandinger
samuel
T.R. Missner
Weiter Leiter