Greger V. Teigre wrote:
A part of the ONsip.org Getting Started effort is to make configuration files that can be used as a reference (and thus should be validated for correctness through theory and scrutiny from community). CANCELs can be in dialog and outside dialog and must thus be handled in two ways. In dialog they should be handled through the loose route (and basically t_relay'ed), while outside dialog they should be handled as INVITEs (credits go to Jan for explaining this in detail). Ex. this configuration file will show you this: http://www.onsip.org/modules/mydownloads/viewcat.php?cid=7
While this link is not accessible I appreciate the explanation.
Thanks.
g-)
a c wrote:
main route block..ac
# main routing logic route{
if (method == "CANCEL"){ t_relay(); }...
--- Steve Blair blairs@isc.upenn.edu wrote:
humm. Where did you put it?
a c wrote:
thanks guys..t_relay was the problem. I did not have this in the config. issue is resolved.
ac --- a c lra101@yahoo.com wrote:
I believe the 487 does not get matched because the UA which does the CANCEL never gets a 200 OK back since the CANCEL was not send out to the terminating UA by SER. For CANCEL, are we supposed to have special config? I don't have any specifically handles CANCEL {other than 487}.
ac
--- Steve Blair blairs@isc.upenn.edu wrote:
I am having a similar problem. I am not yet convinced that it is SER as much as my configuration but if SER does have difficulty processing CANCEL messages it would be helpful to understand under what circumstances.
By the way I have been using t_check_status in
a
similar way since v 0.8 code. When I upgraded to 0.9.0, .0 and now
.2
the t_check_status fails to be matched.
-Steve
Thanks,Steve
a c wrote:
> any ideas anyone? seems like SER does not respond > > to
> CANCEL requests and eventually takes the failure > route. > > I have the following in my failure route, but it > > never
> gets hit, since SER does not send the 200 OK back > > or
> pass the CANCEL message forward. log file > >
attached.
> failure_route[1] > { > if(t_check_status("487")) { > # don't continue on cancellation > xlog("L_WARN", "OH OH OH\n"); > break; > } > > ac > > > --- a c lra101@yahoo.com wrote: > > > > > >> Seems like SER does not respond back to CANCEL >> Requests. Is this a issue / some config problem >> >>
on
>> my >> side? ngrep traces attached >> >> interface: eth0 (192.168.0.0/255.255.255.0) >> filter: ip and ( port 5060 ) >> # >> U 192.168.0.2:5062 -> 192.168.0.5:5060 >> INVITE sip:9999999999@voip.com SIP/2.0..Via: >> SIP/2.0/UDP 192.168.0.2:5062;r >> >> >> >> >> >>
port;branch=z9hG4bKE29503D9D8CF4A479B6D9DDB17C5CFC1..From:
> > > > >> 102 sip:102@voi > p.com:5062>;tag=3282942385..To: >> sip:9999999999@voip.com..Contact: sip:10 > 2@192.168.0.2:5062>..Call-ID: >> 29469D19-CDF1-49ED-8245-A67E1B1DBB88@192.168. >> 0.2..CSeq: 940 INVITE..Max-Forwards: >> 70..Content-Type: application/sdp..Use >> r-Agent: X-Lite release 1103m..Content-Length: >> 258....v=0..o=102 7659613 76 >> 59633 IN IP4 192.168.0.2..s=X-Lite..c=IN IP4 >> 192.168.0.2..t=0 0..m=audio 80 >> 00 RTP/AVP 0 8 3 98 96..a=rtpmap:0 >> pcmu/8000..a=rtpmap:8 pcma/8000..a=rtpma >> p:3 gsm/8000..a=rtpmap:98 >> >>
iLBC/8000..a=rtpmap:96
>> telephone-event/8000..a=fm >> tp:96 0-15.. >> >>
>> >> # >> U 192.168.0.5:5060 -> 192.168.0.2:5062 >> SIP/2.0 100 trying -- your call is important >> >>
to
>> us..Via: SIP/2.0/UDP 192.16 >> >> >> >> >> >>
8.0.2:5062;rport=5062;branch=z9hG4bKE29503D9D8CF4A479B6D9DDB17C5CFC1..From:
> > > > >> 102 >> >>
sip:102@voip.com:5062;tag=3282942385..To:
>> sip:9999999999@voip.com. >> .Call-ID: >> >>
=== message truncated ===
Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers