HI ,
Could you please remove me from this group ?
Thanks !
zahir.jamiza...@cygate.se
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Fair enough. Thank you for all the explanation!
On Mon, 11 Feb 2019 at 16:02, Alex Balashov
wrote:
> On Mon, Feb 11, 2019 at 03:50:01PM +1300, David Cunningham wrote:
>
> > Is that the case always, or only when they're in response to a 200 OK?
>
> There are two kinds of ACKs; end-to-end ACKs (i
On Mon, Feb 11, 2019 at 03:50:01PM +1300, David Cunningham wrote:
> Is that the case always, or only when they're in response to a 200 OK?
There are two kinds of ACKs; end-to-end ACKs (in response to
dialog-establishing 2xx responses of an invite transaction), and
hop-by-hop ACKs (in response to
Is that the case always, or only when they're in response to a 200 OK?
On Mon, 11 Feb 2019 at 14:31, Alex Balashov
wrote:
> On Mon, Feb 11, 2019 at 02:28:51PM +1300, David Cunningham wrote:
>
> > Thank you. This is where I easily get mixed up, because an ACK sounds
> like
> > it should be a rep
On Mon, Feb 11, 2019 at 02:28:51PM +1300, David Cunningham wrote:
> Thank you. This is where I easily get mixed up, because an ACK sounds like
> it should be a reply to the 200 OK.
That's understandable. And ACKs are, of course, unusual. But they are
certainly requests in their own right, not rep
Thank you. This is where I easily get mixed up, because an ACK sounds like
it should be a reply to the 200 OK.
On Mon, 11 Feb 2019 at 14:21, Alex Balashov
wrote:
> On Mon, Feb 11, 2019 at 02:16:50PM +1300, David Cunningham wrote:
>
> > Thank you. So I was correct other than mixing up the Route
On Mon, Feb 11, 2019 at 02:16:50PM +1300, David Cunningham wrote:
> Thank you. So I was correct other than mixing up the Route and Via headers.
> Some day I'll get them right...
:-)
The Via headers determine the path traversed by replies to a request.
They do not influence request routing, incl
Thank you. So I was correct other than mixing up the Route and Via headers.
Some day I'll get them right...
On Mon, 11 Feb 2019 at 14:10, Alex Balashov
wrote:
> On Mon, Feb 11, 2019 at 02:08:18PM +1300, David Cunningham wrote:
>
> > OK, so the Contact is the address on the envelope, but the pos
On Mon, Feb 11, 2019 at 02:08:18PM +1300, David Cunningham wrote:
> OK, so the Contact is the address on the envelope, but the postal service
> should actually send it through the chain of Route headers?
Yes, but once the request exits the last proxy, that last proxy should
set the domain part of
OK, so the Contact is the address on the envelope, but the postal service
should actually send it through the chain of Route headers?
Our issue is that the device is sending the ACK directly to the Contact
address, but the Contact address doesn't support TLS, which is why we need
it to go through
Hello,
An end-to-end ACK should be sent to the Contact in the 200 OK. The
actual network and transport-layer destination will differ due to the
intermediate Record-Route hops.
In RFC parlance, this is known as the "remote target" of the dialog. The
ACK is in substance an in-dialog request, so the
ACK to 200 OK should be sent based on the route set, not VIA.
Regards,
_
Roman Shpount
On Sun, Feb 10, 2019 at 7:48 PM David Cunningham
wrote:
> Hello,
>
> Could someone please confirm the correct routing of an ACK?
> A device receives the following 200 OK. Should the ACK it sends
Hello,
Could someone please confirm the correct routing of an ACK?
A device receives the following 200 OK. Should the ACK it sends in response
be sent to the first Via address? I believe that sending it to the Contact
address is incorrect? If anyone happens to know the part of the RFC that
specifi
13 matches
Mail list logo
