Alexandr Dranchuk wrote: > Got it. My goof. after rereading RFC I found it. > Looks like caller's device support old RFC2543 where it's allowed. > Thus I can nothing to do with coming bogus BYE requests. > actually even from RFC2543 perspective the BYE is bogus ( in RFC2543 the callee contact was added a last Route hdr - which is missing in your BYE ).
> One more question I got, is sometimes I got same BYE after CANCEL without > TO_TAG > > so, the question is what's the best solution? Drop the BYE without TO TAG > or continue > forward it to PSTN GW? > AFIAK, BYE must have a totag as it is a sequential request. I would say you can drop it (anyhow you cannot route it) safely as you already have the CANCEL. Regards, Bogdan > Thank You very much for your previous answers. > > On Wed, 21 Apr 2010 15:25:41 +0300, Bogdan-Andrei Iancu > <[email protected]> wrote: > >> well, first of all, without a 200 OK, it is rather impossible to built a >> > > >> valid BYE. Because the BYE must contain the remove address (of the other >> > > >> party - callee here) and the Route set (all the RR headers) - all this >> info is collected from 200 OK. >> >> So, the RURI in BYE must be the contact in 200 OK INVITE . The INVITE >> and the BYE requests are differently built (first is an initial request, >> > > >> second a sequential request) >> >> Regards, >> Bogdan >> >> Alexandr Dranchuk wrote: >> >>> Hi Bogdan! >>> >>> Sorry for bothering You, but... it's not quite clear to me why the BYE >>> broken? >>> for caller it's unknown callee IP, and for INVITE I call >>> forward(192.168.1.203) function >>> to reach callee. So should I call forward(192.168.1.203) for the BYE >>> also? >>> >>> about invalid BYE, I completely agree about, but have no idea why I get >>> BYE after >>> CANCEL... since I haev no access to caller device, can't check it. >>> >>> Thank You >>> >>> On Wed, 21 Apr 2010 11:02:54 +0300, Bogdan-Andrei Iancu >>> <[email protected]> wrote: >>> >>> >>>> Hi Alexandr, >>>> >>>> First of all, the message in logs says - invalid BYE received while >>>> > the > >>>> call still in early state (call not established yet). That BYE is >>>> > bogus > >>>> - why does the caller sends a BYE after sending a CANCEL ?!?! makes no >>>> > > >>>> sense. >>>> >>>> Second part, with the looping, is not related to the log you get. The >>>> BYE loops because is completely broken : all the routing info (RURI >>>> > and > >>>> Route hdrs) points to proxy only (the 2 interfaces of the proxy) >>>> > without > >>>> >>>> >>> >>> >>>> any reference to the callee IP....so opensips is keep sending to >>>> >>>> >>> itself.... >>> >>> >>>> Regards, >>>> Bogdan >>>> >>>> Alexandr Dranchuk wrote: >>>> >>>> >>>>> Hi! >>>>> >>>>> I got this and now ask if someone can tell me if it's normal or I >>>>> should do something with... >>>>> >>>>> >>>>> >>>>> I debuging OpenSIPS 1.6.2 on multihomed PC with mhomed=1 >>>>> >>>>> where OpenSIPS has public IP 8.8.2.2 and on second interface private >>>>> 192.168.1.200 >>>>> >>>>> calls terminated to gateway 192.168.1.203 >>>>> >>>>> >>>>> >>>>> So issue happens on call not being connected, but right after CANCEL >>>>> when I get BYE method from caller! >>>>> >>>>> >>>>> >>>>> I got this error at every similar BYE >>>>> >>>>> Apr 21 01:18:06 ser /usr/sbin/opensips[590]: >>>>> CRITICAL:dialog:log_next_state_dlg: bogus event 7 in state 2 for dlg >>>>> 0xb3b8e304 [1541:1721026758] with clid '[email protected]' and tags >>>>> '1779091552' 'b151f93a-724884' >>>>> >>>>> >>>>> >>>>> and SIP TRACE shows strange loop of BYE message from 1 interface to >>>>> another at the same host >>>>> >>>>> causing this error: >>>>> -- Bogdan-Andrei Iancu www.voice-system.ro _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
