Re: [Partysip-dev] Call setup problems

[Aymeric Moizard]

On Wed, 23 Apr 2003, Marian Durkovic wrote:

> Hi Aymeric,
>
>   thanks for the fast reply!
>
> Yes, I've tried to use record-routing and unfortunately it opens some other
> problems.... I'm already balancing on a very thin ice, since translators
> between H323 and SIP bring a lot of fun.
>
> Since we're not living in a perfect world, wouldn't it be
> possible to have some option like "workaround_for_broken_clients"
> which will allow to pass the ACKs  through?

If you assume the request-uri contains the correct host destination,
then the fix is quite easy... I think this is the case that will
happen most of the time. Who knows?

By the way, here is a quick fix:

              OSIP_TRACE (osip_trace
                          (__FILE__, __LINE__, OSIP_INFO1, NULL,
                           "core module: This is a late ACK to
discard!\n"));
              /* It can be a ACK for 200 ok, but those ACK SHOULD
                 never go through this proxy! (and should be sent to the
                 contact header of the 200ok */
#define SUPPORT_FOR_BROKEN_UA
#ifdef SUPPORT_FOR_BROKEN_UA
              /* if this ACK has a request-uri that is not us,
                 forward the message there. How should I modify this
                 message?? */

              if (evt!=NULL
                  && evt->sip!=NULL
                  && evt->sip->strtline!=NULL
                  && evt->sip->strtline->rquri!=NULL)
                {
                  if
(psp_core_is_responsible_for_this_domain(evt->sip->strtline->rquri)!=0)
                    {
                      int port = 5060;
                      if (evt->sip->strtline->rquri->port != NULL)
                        port = satoi (evt->sip->strtline->rquri->port);
                      psp_core_cb_snd_message(NULL, evt->sip,

evt->sip->strtline->rquri->host,
                                              port, -1);
                    }
                }
#endif
              msg_free (evt->sip);
              sfree (evt->sip);
              sfree (evt);
              return 0;
            }

It's in the CVS.

The above fix will lead to weird behavior:
 * when receiving late ACK for response other than 2xx
 * when the request-uri does not contains an IP. (you an improve it!)
 * not usefull when the ACK contains a uri pointing to the partysip.

Let me know if this helps you.
Aymeric

>       Thanks,
>
>               M.
>
>
>
> > I don't like them :)
> >
> > > - for example sip-h323
> > > translators, which only talk to the nearest sip proxy and thus are sending
> > > the ACKs after 200 OK to them as well. Also some UAs do it like this.
> > > When partysip drops the ACK, the call could not be established.
> >
> > The rfc does not allow this behavior and mandates to use the
> > record-routing mechanism.
> >
> > There is actually one way to deal with this issue: configure partysip to
> > do "record-routing". This way evry SIP messages will go through the proxy
> > and partysip will handle them correctly. (because of the presence of
> > the Route header). (Note that MSN reply with an error when receiving
> > calls from a proxy that does record-routing and which conforms to
> > the latest rfc... It's not partysip's fault again!)
> >
> > To enable record-routing, you have to modify **evrywhere** in the config
> > file lines. (it appears more than once)
> >
> >   record-route off
> > in
> >   record-route on
> >
> > Aymeric
>