sr-users December 2005

sr-users@lists.kamailio.org

158 participants
313 discussions

Re: [Serusers] Changing Sip Port
by Voipers Portugal 14 Dec '05

14 Dec '05

There are 2 port setting that you can change. Either you change the signalling port to contact SER: when specifying the SIP Server just do: sip_server:port In this case, if you change the port, make sure that your SER Server is listening on that port as well. Or you can change the listen port of your Softphone. In this case, you don't need to alter anything else. Not sure about what you wanted. Can you provide the SIP messages log? Jose Simoes On 12/13/05, Juan <juan(a)uwtcallback.com> wrote: > > > Hi Jose. > I tried your way but I did not get it registred. I used many ports but > couldn't get it registred. > I am not using any authentication and when using port 5060 the softphone > registres OK. > My SER and my softphone (X- lite) are on the same network. > Any ideas? > Thanks in advance, > > Juan Ferrari > United World Telecom > > > ------------------------------ > *From:* serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] *On > Behalf Of *Voipers Portugal > *Sent:* Saturday, December 10, 2005 8:48 AM > *Cc:* serusers(a)lists.iptel.org > *Subject:* Re: [Serusers] Changing Sip Port > > > Most softphones allow that. When you are specifying a SIP server, for > default (normally) it uses 5060. If you want to alter this port just do the > following: > > ser_IP_address:port_number > > 127.0.0.1:5090 > > Jose Simoes > > p.s. this works with X-Lite > > On 12/5/05, Andrey Kouprianov <andrey.kouprianov(a)gmail.com> wrote: > > > > I guess it depends on your softphone... if it chooses to communicate > > from port 5060, there's nothing you can do about it, unless you can > > change it in the phone's settings... > > Some softphones, for instance, get a random port... > > > > On 12/5/05, sagar <vids_cs(a)yahoo.com> wrote: > > > Hi All, > > > > > > I am using ser 0.8.14 +asterisk B2bua. > > > > > > Currently softphone is registering on standard sip port 5060 . > > > Is it possibe to use any other port like 5090 or 8069 > > > > > > > > > I tried to do so by changing the listining port to 5090 in ser.cfgbut in > > > case the softphone is not getting register. > > > > > > > > > Here is the ser log > > > > > > > > > 0(11348) SIP Request: > > > 0(11348) method: <REGISTER> > > > 0(11348) uri: <sip: 192.168.1.100> > > > 0(11348) version: <SIP/2.0> > > > 0(11348) parse_headers: flags=1 > > > 0(11348) end of header reached, state=5 > > > 0(11348) parse_headers: Via found, flags=1 > > > 0(11348) parse_headers: this is the first via > > > 0(11348) After parse_msg... > > > 0(11348) preparing to run routing scripts... > > > 0(11348) DEBUG : is_maxfwd_present: searchi ng for max_forwards > > header > > > 0(11348) parse_headers: flags=128 > > > 0(11348) DEBUG: is_maxfwd_present: value = 70 > > > 0(11348) parse_headers: flags=8 > > > 0(11348) DEBUG: add_param: > > > tag=fa37b062306344d68023aed26289e820 > > > 0(11348) DEBUG: add_param: epid=f657995ecc > > > 0(11348) end of header reached, state=29 > > > 0(11348) parse_headers: flags=256 > > > 0(11348) end of header reached, state=9 > > > 0(11348) DEBUG: get_hdr_field: <To> [37]; > > > uri=[sip:2851816416@192.168.1.100:5090] > > > 0(11348) DEBUG: to body [<sip:2851816416@192.168.1.100:5090> > > > ] > > > 0(11348) get_hdr_field: cseq <CSeq>: <1> <REGISTER> > > > 0(11348) DEBUG: get_hdr_body : content_length=0 > > > 0(11348) found end of header > > > 0(11348) find_first_route(): No Route headers found > > > 0(11348) loose_route(): There is no Route HF > > > 0(11348) parse_headers: flags=64 > > > 0(11348) parse_headers: flags=64 > > > 0(11348) parse_headers: flags=33554432 > > > 0(11348) check_self - checking if host==us: 13==13 && [ > > 192.168.1.100] == > > > [192.168.1.100 ] > > > 0(11348) check_self - checking if port 5090 matches port 5060 > > > 0(11348) check_self: host != me > > > 0(11348) DEBUG: t_addifnew: msg id=1 , global msg id=0 , T on > > > entrance=0xffffffff > > > 0(11348) parse_headers: flags=-1 > > > 0(11348) parse_headers: flags=60 > > > 0(11348) t_lookup_request: start searching: hash=58712, isACK=0 > > > 0(11348) DEBUG: proceeding to pre-RFC3261 transaction matching > > > 0(11348) DEBUG: t_lookup_request: no transaction found > > > 0(11348) DEBUG: mk_proxy: doing DNS lookup... > > > 0(11348) check_via_address(192.168.1.2, 192.168.1.2, 0) > > > 0(11348) DEBUG: add_to_tail_of_timer[4]: 0xb6165fe8 > > > 0(11348) DEBUG: add_to_tail_of_timer[0]: 0xb6165ffc > > > 0(11348) SER: new transacti on fwd'ed > > > 0(11348) DEBUG:destroy_avp_list: destroing list (nil) > > > 0(11348) receive_msg: cleaning up > > > > > > Please advise. > > > > > > Thanks In Advance. > > > > > > > > > ________________________________ > > > Yahoo! Personals > > > Single? There's someone we'd like you to meet. > > > Lots of someones, actually. Yahoo! Personals > > > > > > > > > _______________________________________________ > > > Serusers mailing list > > > serusers(a)lists.iptel.org > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > > > > > > > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > > > >

2 1

Re: [Serusers] Please, help with SUBSCRIBE timeouts
by Andrey Kouprianov 14 Dec '05

14 Dec '05

yes.. thanx On 12/14/05, Vaclav Kubart <vaclav.kubart(a)iptel.org> wrote: > I know such situations from my work too. If the problems show again let me > know... > Vaclav > > On Wed, 14 Dec 2005, Andrey Kouprianov wrote: > > > Thanx a lot for understanding. :)))) > > > > On 12/14/05, Vaclav Kubart <vaclav.kubart(a)iptel.org> wrote: > >> :-) It happens... > >> Vaclav > >> > >> On Wed, 14 Dec 2005, Andrey Kouprianov wrote: > >> > >>> And then again my UA is working OK now... Im just stunned... I have a > >>> deadline for this app. Have to present it on coming friday... Hehe... > >>> If it fails to SUBSCRIBE... I'll be in trouble... > >>> > >>> On 12/14/05, Andrey Kouprianov <andrey.kouprianov(a)gmail.com> wrote: > >>>> Yes, i've noticed that too... And yes my config implies statefull > >>>> forwarding.... I think it's my mistake... I was trying with forward > >>>> instead of t_relay at the time I generated traces... > >>>> > >>> > >>> _______________________________________________ > >>> Serusers mailing list > >>> serusers(a)lists.iptel.org > >>> http://lists.iptel.org/mailman/listinfo/serusers > >>> > >> > > >

2 3

[Serusers] using pa module
by lo ™ 14 Dec '05

14 Dec '05

hi all, i tried to use the presence module "pa.so" (without jabber support or xcap authorization) but i don't understand which functionalities have been fixed and which are currently unstable... i'm using eyebeam and i follow these "Configuring Presence Agent" instructions: http://pals.internet2.edu/trials/pic-ser/eyeBeamInstall.html this is part of my ser.cfg: if (method=="PUBLISH") { if (!t_newtran()) { log(1,"ser.cfg: PUBLISH: t_newtran error\n"); sl_reply_error(); }; log(1,"ser.cfg: PUBLISH: handle_publish\n"); handle_publish("registrar"); break; } else if (method=="SUBSCRIBE") { if (!t_newtran()) { log(1,"ser.cfg: SUBSCRIBE: newtran error\n"); sl_reply_error(); }; log(1,"ser.cfg: SUBSCRIBE: handle_subscription\n"); handle_subscription("registrar"); break; }; is it correct? i would like to see my contacts to eventually change state... is it possible? thank you!

3 3

[Serusers] SIP call hold/unhold
by tcchan 14 Dec '05

14 Dec '05

Dear All, I encountered a UA that behave as follow: UA1 call UA2 UA1 ---- invite with SDP -----> UA2 UA1 <------OK with SDP --------UA2 UA1 hold the call, UA1 ------invite (hold) ------>UA2 UA1 <--------OK but not SDP ---UA2 UA1 unhold the call UA1 ------invite ----------->UA2 UA1 <-------OK but also no SDP---UA2 I found that most ATA(UA) would attached a SDP when reply an OK whether the call is hold or unhold. But there is one ATA that does not (UA2). I noticed that some ATA--Linksys (UA1) would send a BYE to UA2 if it receive a OK with no SDP in the hold case. My Question is : Is UA2 behave according to RFC? Would deeply appreciate if someone could let me know the answer as I always have trouble reading RFCs... Thanks fot any help available. Regards, TC Chan

3 2

Re: [Serusers] end the session if no media-conclusion
by Hakan YASTI 14 Dec '05

14 Dec '05

Dear All, After studied on different scenarios, we can not end the session when there is no rtp on media channels. I have heard that some media proxies can do this (like nextone,acmepacket) but I did not test it. As a brief, if the bye will not come from one of the legs because of network problems, you do not have chance to end the session by checking the rtp packets. How did we solve the problem ? Now we are using a session controller. when a session starts, we start a timer, after 1 hour, if the session is going on we are sending a notify about thr session to the network control center. They can kill the session through the session controller. In any case, after 2 hours later if the session is again going on, we kill it automatically from the session controller and send a notification mail to the sysadmin which contains the session information. In this scenario, my customers do not have sessions more than 2 hours. ----- Original Message ----- From: Greger V. Teigre To: Hakan YASTI Sent: Thursday, November 17, 2005 9:50 AM Subject: Re: [Serusers] end the session if no media Good luck :-) And please copy serusers on your conclusions. g-) ----- Original Message ----- From: Hakan YASTI To: Greger V. Teigre Sent: Wednesday, November 16, 2005 1:46 PM Subject: Re: [Serusers] end the session if no media Dear Greger, sorry for late reply. I was on vacation. The scenario is like that. A ( ATA ) ----------------> send INVITE to SER ------------> SER INVITES to session controller --------> session controller invites to ---------> soft switch --------------call setup to ------PSTN B. After signalling ok, the media is also proxied by SER. A Side ------> ------ media goes to SER --<----------media ----------->Media Gateway--------> B side. Possible scenario ; 1-) The BYE is not coming from A side. At that time I see the session on session controller as going on. But infact it is abondened. You are right when the call is on hold. at that time the rtp will not go also. For this session controller must understand when it is on hold.But in any case, I do not know, how will SER end if there is no media session. As I see, the media is controlled by SER. when the bye has come the media session is ended. In fact, When I study on it, I saw that in some cases I saw that, the BYE is coming to soft switch but soft switch send s reply as 500 INTERNAL Error. This is an also issue is related with my soft switch. I have opened a case for this also. Thanks for your interest. I will inform you about the result. Best Regards, ----- Original Message ----- From: Greger V. Teigre To: Hakan YASTI ; serusers(a)lists.iptel.org ; ritesh.j(a)net4.in Sent: Friday, October 28, 2005 6:53 AM Subject: Re: [Serusers] end the session if no media What I'm saying is that you probably want to differ between a long call that after 59 minutes is put on hold and a terminated call where the BYE never came. Both will show no RTP (dependent on UA). Your session controller may be able to tell you if the call is on hold. With regards to No transaction exist: Do you send the BYE directly to the UA and the UA replies with this? If so, I wouldn't worry too much, it just means that you were right in terminating the call because the UA does know of any call. I'm a bit uncertaint about the error though, looks like you may get it from ser (if you send through ser), then the BYE never reaches the UA. (I would expect the UA to respond Call leg doesn't exist). How do you send the BYE that gives this error and to where? g-) ----- Original Message ----- From: Hakan YASTI To: Greger V. Teigre ; serusers(a)lists.iptel.org ; ritesh.j(a)net4.in Sent: Thursday, October 27, 2005 10:25 AM Subject: RE: [Serusers] end the session if no media Yes, I know about it. I can see the active sessions from the session.py. But do not know how to end the seesion, if there is no rtp session and the bye has not come. My session con troller does not check the rtp session because the media is proxied at SER. As I know, may be I am wrong, the ser is managing the media proxy. Ser says to media proxy to start when a call is proxied, and end when the call is finished. Do you suggest a SBC that can do this function..? Thanks, Best Regards, ------------------------------------------------------------------------ From: Greger V. Teigre [mailto:greger@teigre.com] Sent: Thursday, October 27, 2005 9:20 AM To: Hakan YASTI; serusers(a)lists.iptel.org; ritesh.j(a)net4.in Subject: Re: [Serusers] end the session if no media session.py will show if the session is active. Also when a call is put on hold, there will be no rtp stream. I don't know if your SBC handles that. Or is your question something else? g-) ----- Original Message ----- From: Hakan YASTI To: Greger V. Teigre ; serusers(a)lists.iptel.org ; ritesh.j(a)net4.in Sent: Wednesday, October 26, 2005 09:18 AM Subject: RE: [Serusers] end the session if no media Hi Teigre, Thanks for your reply and kind suggestions. In fact, I am using a session controller for sip calls. And it alerts me via email when a sessiıon is reached for about 60 minutes. At that time, I check it manually and kil the session if the session is abondened. By sending BYE messages to both legs. From the PSTN side I get the reply what I assume ( 200 OK ) but from the sip side I get No transaction exist. Because the session was ended before and session controller couldn’t get the BYE message for some reasons. ( Network failure or something else ). What I am looking for that, from the media proxy, I see the active rtp session when I use media proxy for the calls. And I assume that, when the call has finished and couldn’t send or get BYE message, there will be no rtp stream going on. May be I am wrong for this. If rtp session is still open when the a side hunp up and couldn’t send bye , there is nothing to do except killing the session with sending bye messages to both sides, because there is no way to understand the call is active or not. Best Regards, Hakan ---------------------------------------------------------------------- From: Greger V. Teigre [mailto:greger@teigre.com] Sent: Wednesday, October 26, 2005 10:00 AM To: Hakan YASTI; serusers(a)lists.iptel.org; ritesh.j(a)net4.in Subject: Re: [Serusers] end the session if no media Hakan and Ritesh, It seems to me that you are both asking about the same thing. This topic has been discussed many times on serusers. Search google (site:mail.iptel.org) for "BYE stateful sipsak", I'm pretty sure you will get some info. Also, this FAQ could help: http://www.onsip.org/modules/xoopsfaq/index.php?cat_id=3#q2 g-) ----- Original Message ----- From: Hakan YASTI To: serusers(a)lists.iptel.org Sent: Thursday, October 13, 2005 09:13 AM Subject: [Serusers] end the session if no media Hi, I wonder, is there any way, to end the session when the media has ended. Sometimes, we have problem at BYE message. For some reasons, the bye is not coming and may be it is coming wrong. At that time, the media is ended but the call is seen as active. I am using ser and using media proxy. Any suggestion for this issue ? Best Regards, Hakan YASTI NGN Engineer Teletek Telekomünikasyon Hizmetleri A.Þ. Ayazma Dere Cad. Akþit Plaza No:12 Fulya, Beþiktaþ ISTANBUL - TURKEY Tel : +90 212 310 22 34 Fax : +90 212 227 8700 GSM : +90 533 669 06 84 E-mail: hakan.yasti(a)teletek.net http://www.teletek.net -------------------------------------------------------------------- _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers Disclaimer: This e-mail (including any attachments) may contain confidential and/or privileged information. Copying, disclosure or distribution of the material in this e-mail without our companys' authority is strictly forbidden. If you are not the intended recipient (or have received this e-mail in error), please notify the sender and delete it from your system immediately. Our Company makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. Any opinions expressed in this message are those of the author and may not necessarily reflect the opinions of Our Company. Yasal Uyarı: Bu e-posta'nin içerdigi bilgiler (ekleri de dahil olmak üzere) gizlidir. Şirketimizin onayı olmaksızın içeriği kopyalanamaz, üçüncü kişilere açıklanamaz veya iletilemez . Bu mesajın gönderilmek istendiği kişi değilseniz (ya da bu e-posta’yı yanlışlıkla aldıysanız), lütfen yollayan kişiyi haberdar ediniz ve mesajı sisteminizden derhal siliniz. Şirketimiz bu mesajın içerdigi bilgilerin doğruluğu veya eksiksiz olduğu konusunda bir garanti vermemektedir. Bu nedenle bilgilerin ne şekilde olursa olsun içeriğinden, iletilmesinden, alınmasından, saklanmasından sorumlu değildir. Bu mesajın içeriği yazarına ait olup, Şirketimizin görüşlerini içermeyebilir. Disclaimer: This e-mail (including any attachments) may contain confidential and/or privileged information. Copying, disclosure or distribution of the material in this e-mail without our companys' authority is strictly forbidden. If you are not the intended recipient (or have received this e-mail in error), please notify the sender and delete it from your system immediately. Our Company makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. Any opinions expressed in this message are those of the author and may not necessarily reflect the opinions of Our Company. Yasal Uyarı: Bu e-posta'nin içerdigi bilgiler (ekleri de dahil olmak üzere) gizlidir. Şirketimizin onayı olmaksızın içeriği kopyalanamaz, üçüncü kişilere açıklanamaz veya iletilemez . Bu mesajın gönderilmek istendiği kişi değilseniz (ya da bu e-posta’yı yanlışlıkla aldıysanız), lütfen yollayan kişiyi haberdar ediniz ve mesajı sisteminizden derhal siliniz. Şirketimiz bu mesajın içerdigi bilgilerin doğruluğu veya eksiksiz olduğu konusunda bir garanti vermemektedir. Bu nedenle bilgilerin ne şekilde olursa olsun içeriğinden, iletilmesinden, alınmasından, saklanmasından sorumlu değildir. Bu mesajın içeriği yazarına ait olup, Şirketimizin görüşlerini içermeyebilir. -------------------------------------------------------------------------- _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

1 0

[Serusers] subscription
by hgaillac-sip＠yahoo.fr 14 Dec '05

14 Dec '05

___________________________________________________________________________ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com ___________________________________________________________________________ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com

1 0

[Serusers] Help installation of SER!
by carlos moreno 14 Dec '05

14 Dec '05

Good morning, friends, nice to meet you, My name is Carlos Manuel Moreno, from Venezuela, has anyone installed SER, from a RPM file? Which is the correct process? Thanks in advance, Carlos _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 2

Re: [Serusers] Please, help with SUBSCRIBE timeouts
by Andrey Kouprianov 14 Dec '05

14 Dec '05

Yes, that's correct... The UA on that IP address is registered and running... On 12/14/05, Vaclav Kubart <vaclav.kubart(a)iptel.org> wrote: > From the trafic it seems, that the authorized SUBSCRIBE is forwarded to > 203.159.32.38. Isn't it correct? > Vaclav > > On Wed, 14 Dec 2005, Andrey Kouprianov wrote: > > > Hi, > > > > Yes, i have tried w/o authorization, but the result is the same. > > The traces are from the client side... As you suggested I dumped the > > traces on the server side with ngrep on both network interface and > > loopback... Loopback yielded no outcome whatsoever (ngrep -W byline -d > > lo0 port 5060). Here are the traces from the from the network > > iterface.... > > > > interface: fxp0 (203.159.31.0/255.255.255.0) > > filter: (ip or ip6) and ( port 5060 ) > > # > > U 203.159.32.39:5060 -> 203.159.31.36:5060 > > SUBSCRIBE sip:12345@sip.interlab.ait.ac.th SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 1 SUBSCRIBE. > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK6789ffc624cbb73dbc918bda9a71956f. > > Max-Forwards: 70. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Content-Length: 0. > > . > > > > # > > U 203.159.31.36:5060 -> 203.159.32.39:5060 > > SIP/2.0 401 Unauthorized. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 1 SUBSCRIBE. > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > To: <sip:12345@sip.interlab.ait.ac.th>;tag=1a5a85ff3e08e000f4c2527642cf14ac.8ccb. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK6789ffc624cbb73dbc918bda9a71956f. > > WWW-Authenticate: Digest realm="sip.interlab.ait.ac.th", > > nonce="439fcec8acac4e38ab93d42a6c610db886870639". > > Server: Sip EXpress router (0.9.3 (i386/freebsd)). > > Content-Length: 0. > > Warning: 392 203.159.31.36:5060 "Noisy feedback tells: pid=279 > > req_src_ip=203.159.32.39 req_src_port=5060 > > in_uri=sip:12345@sip.interlab.ait.ac.th > > out_uri=sip:12345@sip.interlab.ait.ac.th via_cnt==1". > > . > > > > # > > U 203.159.32.39:5060 -> 203.159.31.36:5060 > > SUBSCRIBE sip:12345@sip.interlab.ait.ac.th SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 70. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.31.36:5060 -> 203.159.32.38:5060 > > SUBSCRIBE sip:12345@203.159.32.38:5060 SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP 203.159.31.36;branch=0. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 16. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.32.39:5060 -> 203.159.31.36:5060 > > SUBSCRIBE sip:12345@sip.interlab.ait.ac.th SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 70. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.31.36:5060 -> 203.159.32.38:5060 > > SUBSCRIBE sip:12345@203.159.32.38:5060 SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP 203.159.31.36;branch=0. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 16. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.32.39:5060 -> 203.159.31.36:5060 > > SUBSCRIBE sip:12345@sip.interlab.ait.ac.th SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 70. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.31.36:5060 -> 203.159.32.38:5060 > > SUBSCRIBE sip:12345@203.159.32.38:5060 SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP 203.159.31.36;branch=0. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 16. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.32.39:5060 -> 203.159.31.36:5060 > > SUBSCRIBE sip:12345@sip.interlab.ait.ac.th SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 70. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.31.36:5060 -> 203.159.32.38:5060 > > SUBSCRIBE sip:12345@203.159.32.38:5060 SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP 203.159.31.36;branch=0. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 16. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.32.39:5060 -> 203.159.31.36:5060 > > SUBSCRIBE sip:12345@sip.interlab.ait.ac.th SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 70. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.31.36:5060 -> 203.159.32.38:5060 > > SUBSCRIBE sip:12345@203.159.32.38:5060 SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP 203.159.31.36;branch=0. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 16. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.32.39:5060 -> 203.159.31.36:5060 > > SUBSCRIBE sip:12345@sip.interlab.ait.ac.th SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 70. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.31.36:5060 -> 203.159.32.38:5060 > > SUBSCRIBE sip:12345@203.159.32.38:5060 SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP 203.159.31.36;branch=0. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 16. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.32.39:5060 -> 203.159.31.36:5060 > > SUBSCRIBE sip:12345@sip.interlab.ait.ac.th SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 70. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.31.36:5060 -> 203.159.32.38:5060 > > SUBSCRIBE sip:12345@203.159.32.38:5060 SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP 203.159.31.36;branch=0. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 16. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.32.39:5060 -> 203.159.31.36:5060 > > SUBSCRIBE sip:12345@sip.interlab.ait.ac.th SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 70. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.31.36:5060 -> 203.159.32.38:5060 > > SUBSCRIBE sip:12345@203.159.32.38:5060 SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP 203.159.31.36;branch=0. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 16. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.32.39:5060 -> 203.159.31.36:5060 > > SUBSCRIBE sip:12345@sip.interlab.ait.ac.th SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 70. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.31.36:5060 -> 203.159.32.38:5060 > > SUBSCRIBE sip:12345@203.159.32.38:5060 SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP 203.159.31.36;branch=0. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 16. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.32.39:5060 -> 203.159.31.36:5060 > > SUBSCRIBE sip:12345@sip.interlab.ait.ac.th SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 70. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.31.36:5060 -> 203.159.32.38:5060 > > SUBSCRIBE sip:12345@203.159.32.38:5060 SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP 203.159.31.36;branch=0. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 16. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.32.39:5060 -> 203.159.31.36:5060 > > SUBSCRIBE sip:12345@sip.interlab.ait.ac.th SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 70. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > # > > U 203.159.31.36:5060 -> 203.159.32.38:5060 > > SUBSCRIBE sip:12345@203.159.32.38:5060 SIP/2.0. > > Call-ID: 71c1bf26356a141742e567a5e9df81e1(a)203.159.32.39. > > CSeq: 2 SUBSCRIBE. > > To: <sip:12345@sip.interlab.ait.ac.th>. > > Via: SIP/2.0/UDP 203.159.31.36;branch=0. > > Via: SIP/2.0/UDP > > 203.159.32.39:5060;branch=z9hG4bK77df80e3df85663fd666b9fcc970b54b. > > Max-Forwards: 16. > > Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE. > > User-Agent: IntERLab User Agent 1.0a. > > Event: presence. > > Expires: 600. > > Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml. > > Contact: <sip:andrey@203.159.32.39:5060>. > > Authorization: Digest > > username="andrey",realm="sip.interlab.ait.ac.th",nonce="439fcec8acac4e38ab93d42a6c610db886870639",uri="sip:12345@sip.interlab.ait.ac.th",response="414329461496b84d3b006a25d11aabab". > > From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=6278953. > > Content-Length: 0. > > . > > > > exit > > 100954 received, 0 dropped > > > > It seems that SER does not even reply with timeout... The timeout is > > probably generated by my JAIN-SIP... Im not sure, anyway... > > > > What is happening here??? > > > > > > > > > > > > On 12/14/05, Vaclav Kubart <vaclav.kubart(a)iptel.org> wrote: > >> Hello, > >> have you tried it without authorization? Any changes in behaviour? > >> The network dump is from the machine with SER or from the client? > > (Could > >> you try do such dump on machine with SER on all interfaces including > >> loopback?) > >> Vaclav > >> > >> On Wed, 14 Dec 2005, Andrey Kouprianov wrote: > >> > >>> Hi, > >>> > >>> This is my 3rd email on this issue.. Please, help me with it. > >>> > >>> I am having the problem with SUBSCRIBE requests in ser 0.9.3. I am not > >>> using PA module, > >>> because my PA and Watcher are located on the client side. > >>> > >>> Whenever I try to subscribe to a presence with any entity OTHER than > >>> myself, SER seems to receive the SUBSCRIBE request, however, it does > >>> not forward it. Instead my application keeps on retransmitting > >>> SUBSCRIBEs until SER replies with 408 Timeout... The same things > >>> happen with NOTIFYs. > >>> > >>> I must also mention that it is NOT all the time that SER replies with > >>> timeout... Just most of the times. And only sometimes it lets the > >>> SUBSCRIBE through (for that, I have to restart my app. again and > >>> again, until I get the right result). > >>> > >>> I included ser.cfg + traces. I've tried to use stateless forwarding ( > >>> forward(uri:host, uri:port) ) instead of stateful (as shown in my > >>> ser.cfg), but it didnt work either. > >>> > >>> Please, tell me what is wrong, because I'm out of ideas here... I > >>> would settle even for reinstalling SER, if it's necessary. > >>> > >>> Here's ser.cfg: > >>> > >>> # ----------- global configuration parameters ------------------------ > >>> debug=3 # debug level (cmd line: -dddddddddd) > >>> fork=yes > >>> log_stderror=no # (cmd line: -E) > >>> > >>> /* Uncomment these lines to enter debugging mode > >>> fork=no > >>> log_stderror=yes > >>> */ > >>> > >>> check_via=no # (cmd. line: -v) > >>> dns=no # (cmd. line: -r) > >>> rev_dns=no # (cmd. line: -R) > >>> #port=5060 > >>> #children=4 > >>> fifo="/tmp/ser_fifo" > >>> fifo_mode=0766 > >>> > >>> sip_warning=yes > >>> server_signature=yes > >>> > >>> alias=sip.interlab.ait.ac.th > >>> > >>> # ------------------ module loading ---------------------------------- > >>> # Uncomment this if you want to use SQL database > >>> loadmodule "/usr/local/lib/ser/modules/mysql.so" > >>> loadmodule "/usr/local/lib/ser/modules/sl.so" > >>> loadmodule "/usr/local/lib/ser/modules/tm.so" > >>> loadmodule "/usr/local/lib/ser/modules/rr.so" > >>> loadmodule "/usr/local/lib/ser/modules/maxfwd.so" > >>> loadmodule "/usr/local/lib/ser/modules/usrloc.so" > >>> loadmodule "/usr/local/lib/ser/modules/registrar.so" > >>> loadmodule "/usr/local/lib/ser/modules/textops.so" > >>> loadmodule "/usr/local/lib/ser/modules/auth.so" > >>> loadmodule "/usr/local/lib/ser/modules/auth_db.so" > >>> loadmodule "/usr/local/lib/ser/modules/uri.so" > >>> loadmodule "/usr/local/lib/ser/modules/uri_db.so" > >>> loadmodule "/usr/local/lib/ser/modules/exec.so" > >>> loadmodule "/usr/local/lib/ser/modules/pa.so" > >>> > >>> # ----------------- setting module-specific parameters --------------- > >>> modparam("usrloc", "db_mode", 2) > >>> modparam("auth_db", "calculate_ha1", yes) > >>> modparam("auth_db", "password_column", "password") > >>> modparam("rr", "enable_full_lr", 1) > >>> > >>> # ------------------------- request routing logic ------------------- > >>> route{ > >>> > >>> # initial sanity checks -- messages with > >>> # max_forwards==0, or excessively long requests > >>> if (!mf_process_maxfwd_header("10")) { > >>> log(1, "Message has too many hops. Message disgarted"); > >>> sl_send_reply("483","Too Many Hops"); > >>> break; > >>> }; > >>> if (msg:len >= 4096 ) { > >>> log(1, "Message too big. Message disgarted"); > >>> sl_send_reply("513", "Message too big"); > >>> break; > >>> }; > >>> > >>> #if (method!="REGISTER" ) record_route(); > >>> > >>> #if (loose_route()) { > >>> # # mark routing logic in request > >>> # append_hf("P-hint: rr-enforced\r\n"); > >>> # route(1); > >>> # break; > >>> #}; > >>> > >>> if (!uri==myself) { > >>> # mark routing logic in request > >>> append_hf("P-hint: outbound\r\n"); > >>> route(1); > >>> break; > >>> }; > >>> > >>> if (uri==myself) { > >>> if (method=="REGISTER") { > >>> if (!www_authorize("sip.interlab.ait.ac.th", "subscriber")) { > >>> log(1, "Authentication for REGISTER"); > >>> www_challenge("sip.interlab.ait.ac.th", "0"); > >>> break; > >>> }; > >>> > >>> #if(!is_user("replicator") & !check_to() ){ > >>> # log(1, "Unregistered user registration attempt\n"); > >>> # sl_send_reply("403", "Forbidden - Registered > >>> users only"); > >>> # break; > >>> #}; > >>> > >>> if(!save("location")) { > >>> log(1, "Error saving AOR"); > >>> sl_reply_error(); > >>> }; > >>> break; > >>> }; > >>> > >>> lookup("aliases"); > >>> if (uri!=myself) { > >>> append_hf("P-hint: outbound alias\r\n"); > >>> route(1); > >>> break; > >>> }; > >>> > >>> #Handle local offline or non-existent users > >>> if(method=="INVITE") { > >>> if(!lookup("location") ) { > >>> log(1, "INVITE for an offline user processing"); > >>> route(3); #offline and non-existent users > >>> break; > >>> }; > >>> }; > >>> > >>> if(method=="SUBSCRIBE") { > >>> if (!www_authorize("sip.interlab.ait.ac.th", "subscriber")) { > >>> log(1, "Authentication for SUBSCRIBE"); > >>> www_challenge("sip.interlab.ait.ac.th", "0"); > >>> break; > >>> }; > >>> > >>> if(!lookup("location") ) { > >>> log(1, "No registered user found for SUBSCRIBE"); > >>> > >>> sl_send_reply("404", "Not Found"); > >>> break; > >>> }; > >>> }; > >>> > >>> # native SIP destinations are handled using our USRLOC DB > >>> if(method=="NOTIFY") { > >>> if (!lookup("location")) { > >>> sl_send_reply("404", "Not Found"); > >>> break; > >>> }; > >>> > >>> log(1, "NOTIFY reveived"); > >>> }; > >>> }; > >>> > >>> append_hf("P-hint: usrloc applied\r\n"); > >>> route(1); > >>> } > >>> > >>> route[1] > >>> { > >>> # send it out now; use stateful forwarding as it works reliably > >>> # even for UDP2TCP > >>> if (!t_relay()) { > >>> sl_reply_error(); > >>> }; > >>> } > >>> > >>> # ------------ Process offline and non-existent users ---------- > >>> route[3] { > >>> # do not continue if it is a retransmission > >>> if(!t_newtran()) { > >>> sl_reply_error(); > >>> break; > >>> }; > >>> > >>> # use external script to send an email notification in case > >>> # user is offline, or just reply back with 404 (Not Found) if > >>> # the user is not a registered user > >>> if(!exec_msg('/home/andrey/sip_email.sh') ) { > >>> t_reply("404", "Not Found - User does not exist"); > >>> } > >>> else { > >>> t_reply("404", "Not Found - User offline"); > >>> }; > >>> break; > >>> } > >>> > >>> . . . . . . . . > >>> > >>> > >>> Here are the traces: > >>> > >>> Message 1 from 203.159.32.39:5060 to 203.159.31.36:5060 > >>> > >>> > >>> SUBSCRIBE sip:12345@sip.interlab.ait.ac.th SIP/2.0 > >>> Call-ID: 7762edc6f3954c87c8b95a0270653250(a)203.159.32.39 > >>> CSeq: 1 SUBSCRIBE > >>> From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=15493888 > >>> To: <sip:12345@sip.interlab.ait.ac.th> > >>> Via: SIP/2.0/UDP > >>> 203.159.32.39:5060;branch=z9hG4bK3ad443c5b49de4b050bd2b028597a868 > >>> Max-Forwards: 70 > >>> Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE > >>> User-Agent: IntERLab User Agent 1.0a > >>> Event: presence > >>> Expires: 600 > >>> Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml > >>> Contact: <sip:andrey@203.159.32.39:5060> > >>> Content-Length: 0 > >>> > >>> > >>> > >>> Message 2 from 203.159.31.36:5060 to 203.159.32.39:5060 > >>> > >>> > >>> SIP/2.0 401 Unauthorized > >>> Call-ID: 7762edc6f3954c87c8b95a0270653250(a)203.159.32.39 > >>> CSeq: 1 SUBSCRIBE > >>> From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=15493888 > >>> To: <sip:12345@sip.interlab.ait.ac.th>;tag=1a5a85ff3e08e000f4c2527642cf14ac.5e75 > >>> Via: SIP/2.0/UDP > >>> 203.159.32.39:5060;branch=z9hG4bK3ad443c5b49de4b050bd2b028597a868 > >>> WWW-Authenticate: Digest > >>> realm="sip.interlab.ait.ac.th",nonce="439ee222efefefbb8cbb78e75d6d15b723a1e1d0" > >>> Server: Sip EXpress router (0.9.3 (i386/freebsd)) > >>> Warning: 392 203.159.31.36:5060 "Noisy feedback tells: pid=17754 > >>> req_src_ip=203.159.32.39 req_src_port=5060 > >>> in_uri=sip:12345@sip.interlab.ait.ac.th > >>> out_uri=sip:12345@sip.interlab.ait.ac.th via_cnt==1" > >>> Content-Length: 0 > >>> > >>> > >>> > >>> Message 3 from 203.159.32.39:5060 to 203.159.31.36:5060 > >>> > >>> > >>> SUBSCRIBE sip:12345@sip.interlab.ait.ac.th SIP/2.0 > >>> Call-ID: 7762edc6f3954c87c8b95a0270653250(a)203.159.32.39 > >>> CSeq: 2 SUBSCRIBE > >>> To: <sip:12345@sip.interlab.ait.ac.th> > >>> Via: SIP/2.0/UDP > >>> 203.159.32.39:5060;branch=z9hG4bK991c906a283ca5d57e8856c98097e81c > >>> Max-Forwards: 70 > >>> Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE > >>> User-Agent: IntERLab User Agent 1.0a > >>> Event: presence > >>> Expires: 600 > >>> Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml > >>> Contact: <sip:andrey@203.159.32.39:5060> > >>> Authorization: Digest > >>> username="andrey",realm="sip.interlab.ait.ac.th",nonce="439ee222efefefbb8cbb78e75d6d15b723a1e1d0",uri="sip:12345@sip.interlab.ait.ac.th",response="1c7fa7ceb1f654d0e2ea91c54823bb8d" > >>> From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=15493888 > >>> Content-Length: 0 > >>> > >>> > >>> > >>> Message 4 from 203.159.32.39:5060 to 203.159.31.36:5060 > >>> > >>> > >>> SUBSCRIBE sip:12345@sip.interlab.ait.ac.th SIP/2.0 > >>> Call-ID: 7762edc6f3954c87c8b95a0270653250(a)203.159.32.39 > >>> CSeq: 2 SUBSCRIBE > >>> To: <sip:12345@sip.interlab.ait.ac.th> > >>> Via: SIP/2.0/UDP > >>> 203.159.32.39:5060;branch=z9hG4bK991c906a283ca5d57e8856c98097e81c > >>> Max-Forwards: 70 > >>> Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE > >>> User-Agent: IntERLab User Agent 1.0a > >>> Event: presence > >>> Expires: 600 > >>> Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml > >>> Contact: <sip:andrey@203.159.32.39:5060> > >>> Authorization: Digest > >>> username="andrey",realm="sip.interlab.ait.ac.th",nonce="439ee222efefefbb8cbb78e75d6d15b723a1e1d0",uri="sip:12345@sip.interlab.ait.ac.th",response="1c7fa7ceb1f654d0e2ea91c54823bb8d" > >>> From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=15493888 > >>> Content-Length: 0 > >>> > >>> > >>> > >>> Message 5 from 203.159.32.39:5060 to 203.159.31.36:5060 > >>> > >>> > >>> SUBSCRIBE sip:12345@sip.interlab.ait.ac.th SIP/2.0 > >>> Call-ID: 7762edc6f3954c87c8b95a0270653250(a)203.159.32.39 > >>> CSeq: 2 SUBSCRIBE > >>> To: <sip:12345@sip.interlab.ait.ac.th> > >>> Via: SIP/2.0/UDP > >>> 203.159.32.39:5060;branch=z9hG4bK991c906a283ca5d57e8856c98097e81c > >>> Max-Forwards: 70 > >>> Allow: REGISTER,INVITE,BYE,ACK,CANCEL,SUBSCRIBE,NOTIFY,MESSAGE > >>> User-Agent: IntERLab User Agent 1.0a > >>> Event: presence > >>> Expires: 600 > >>> Accept: application/pidf+xml,application/xpidf+xml,application/xvcresource+xml > >>> Contact: <sip:andrey@203.159.32.39:5060> > >>> Authorization: Digest > >>> username="andrey",realm="sip.interlab.ait.ac.th",nonce="439ee222efefefbb8cbb78e75d6d15b723a1e1d0",uri="sip:12345@sip.interlab.ait.ac.th",response="1c7fa7ceb1f654d0e2ea91c54823bb8d" > >>> From: "Andrey Kuprianov" <sip:andrey@sip.interlab.ait.ac.th>;tag=15493888 > >>> Content-Length: 0 > >>> > >>> . . . . . . > >>> > >>> And so it goes, until SER replies with Timeout. > >>> > >>> Can you tell me what is wrong??? > >>> > >>> Andrey. > >>> > >>> _______________________________________________ > >>> Serusers mailing list > >>> serusers(a)lists.iptel.org > >>> http://lists.iptel.org/mailman/listinfo/serusers > >>> > >> > > >

2 11

[Serusers] SER with presence release
by Andrey Kouprianov 14 Dec '05

14 Dec '05

Hi, Dont mean to bother much, but when is stable SER with presence support will be made available?

3 5

[Serusers] SUBSCRIBEs and NOTIFYs timeout
by Andrey Kouprianov 14 Dec '05

14 Dec '05

Hi, Im using ser 0.9.3. The PA and Watcher are located on my UA, so basically my SUBSCRIBEs and NOTIFYs just need to be forwarded between clients. Here's a part of ser.cfg that does the SUBSCRIBE and NOTIFY processing (please, note that I disabled the authentication for now): . . . . . . if(method=="SUBSCRIBE") { if(!lookup("location") ) { log(1, "No registered user found for SUBSCRIBE request"); sl_send_reply("404", "Not Found"); break; }; }; if(method=="NOTIFY") { if (!lookup("location")) { log(1, "No registered user found for NOTIFY request"); sl_send_reply("404", "Not Found"); break; }; }; if( !t_relay() ) { sl_reply_error(); }; . . . . . . . . The problem is that only SOMETIMES SUIBSCRIBEs and NOTIFYs get through without any problem. However, MOST OF THE TIMES they get stuck in the server. The message log does not show any errors and tracesviewer tool shows only retransmissions for the issued requests. In the end SER replies with 408 Timeout response. I have tried to use forward(uri:host, uri:port) instead of t_relay(), but result is the same. I have used eyeBeam to do the presence subscriptions, and the result is the same as with my UA... Can you, please, explain to me what might have happened??? I am out of ideas. Andrey.

2 7

← Newer
1
...
11
12
13
14
15
16
17
...
32
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users December 2005