2017-03-30 23:33 GMT+02:00 Rudolf Svanda <address@hidden>:
Hi Aymeric,
we are using eXosip layer.
I can provide you with network capture with which we have problem.
And as i wrote, UPDATE results in EXOSIP_MESSAGE_NEW, but expected
is EXOSIP_CALL_MESSAGE_NEW.
BR
Rudi
Am Donnerstag, den 30.03.2017, 18:46 +0200 schrieb Aymeric Moizard:
> Hi Rudolf!
>
> Is this a report for osip? Or exosip?
>
> In layer exosip, I do use the standard osip methods for checking
> dialogs, but I have sometimes exceptions.
>
> May be this one is among the required exception!
>
> Let me know what layer you use and what method you use!
>
> Regards
> Aymeric
>
>
> Le 30 mars 2017 4:59 PM, "Rudolf Svanda" <address@hidden
> > a écrit :
> > Hi Aymeric,
> >
> > i've got following network trace:
> >
> > UA1 UA2
> > >
> > > INVITE |
> > > --------------------->|
> > > 180 Ringing |
> > > <---------------------|
> > > 183 Session Progress |
> > > <---------------------|
> > > UPDATE |
> > > <---------------------|
> > and so on.
> >
> > In UPDATE UA2 changed "tag" parameter in "from" header, which
> > results
> > in "New request outside call".
> >
> > UAC behaviour is defined in RFC 3261:
> > ---
> > 12.2.1.1 Generating the Request
> > The From URI of the request MUST be set to the local URI from the
> > dialog state. The tag in the From header field of the request MUST
> > be
> > set to the local tag of the dialog ID.
> > ---
> >
> > But is it legal that local tag of the UA2 dialog ID change?
> > In that case implementation in osip_dialog_match_as_uas is
> > wrong and
> > tag should not be considered but taken from request into local
> > dialog
> > state as a remote tag of the UA1 dialog ID.
> >
> > Thanks for answer.
> >
> > BR
> > Rudi
> >
> >
> > _______________________________________________
> > osip-dev mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/osip-dev
> >