2011/3/18 Raphael Coeffic <[email protected]> > On 18.03.11 11:15, Alekzander Spiridonov wrote: > >> >> >> We have lots of sip-gateways that put some random values in >> SIP contact field in SIP 200 OK, so we're unable to send a >> Re-Invite on such request uri. >> >> >> This quite bad... Where is the BYE sent then? >> >> As for the last check foreign device accepted all Messages but Invite on a >> contact URI. And it replied with 420 Bad Extension for a Re-Invite on a >> contact R.URI. >> > > If those devices do not have a 100% own understanding of the standards, > that might mean that some header or announced extension might disturb the > device. It is in fact very uncommon to not support re-INVITE. Even the most > stupid PSTN gateways I have seen were supporting it. > > You probably want to tweak the re-INVITE message. If you manage to make > those devices accept your re-invites, the world looks much more friendly for > 3rd-party-call-control ;-)
> > >> >> Thank you for suggesting a solution. >> >> P.S.: Is there a full list of predefined variables (such >> as@user, #key)? >> >> For which application / API ? Do you mean in DSM? >> >> >> Yes, for using in DSM. As for now, I want to check the source ip of the >> received invite - is it possible? >> >> Nope, but it is fairly easy to add. Please have a look at DSMCall.cpp. In > onSipRequest and onSipReply, you will see some params being assigned (ex: > params["from"] = req.from). You can extend it there with: > > onSipRequest(): > params["remote_ip"] = req.remote_ip > > onSipReply(): > params["remote_ip"] = reply.remote_ip > Will it be taken from ip headers? > > Cheers > Raphael. > -- С уважением, Александр Спиридонов
_______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
