suggestion. The messages between the servers are transferred
via a TCP connection (and all to the same IP address). So I think it should be
well received by the server.
I am still clueless...
Thanks,
Peter
Am Donnerstag, 20. Februar 2020, 11:00:56 CET schrieb Richard Phernambucq:
Hi,
Header-wise
Hi,
Header-wise your ACK appears OK.
I suspect your problem is that the destination address for the ACK
(200.200.200.200) is not routable from your SIP-server. This might
explain why the provider's server keeps retransmitting the response.
BR,
Richard
On 20-2-2020 10:39, Dr. Peter Sties wro
61' (RFC 3261 8.1.2)
I don't understand why the re-SUBSCRIBE request would be sent to port
53426, which seems to be the port the subscriber can be reached at by
the notifier.
Thank you for your time and any clarifications.
Best regards,
Richard Phernambucq
On 23-7-2019 03:03, Pa
to:o...@edvina.net>> wrote:
> On 19 Dec 2018, at 09:28, Richard Phernambucq
mailto:r.phernamb...@cuperus.nl>> wrote:
>
> Hi Amarnath,
>
> A Re-Invite without SDP is called a late offer and isn't the
same as resuming a call that was pla
Hi Amarnath,
A Re-Invite without SDP is called a late offer and isn't the same as
resuming a call that was placed on hold.
If 'UAS' wanted to resume the call it should have sent an SDP body with
sendrecv attribute.
Best regards,
Richard
On 19-12-2018 06:28, Amarnath Kanchivanam wrote:
Hi
o both offer and answer must
indicate the same codec. The payload type number is used in the payload
type field of sent RTP packets to indicate to the receiving side which
format this RTP packet's payload is in.
Best regards,
Richard Phernambucq
On 29-10-2018 12:10, Philipp Schöning wrote
f making use of any of those
formats during the session. In other words, the answerer MAY change
formats in the middle of the session, making use of any of the
formats listed, without sending a new offer.
Best regards,
Richard Phernambucq
On 29-10-2018 10:14, Philipp Schöning wrote:
Hi R
same
codec, so that an updated offer could also use payload type number 72
Best regards,
Richard Phernambucq
On 27-10-2018 14:52, Philipp Schöning wrote:
Hi all,
we saw a SIP implementation violating the SDP offer/answer procedure when
answering a Re-Invite.
Here is the signalling:
S
Hi,
This is a question for which I can't find the answer in the SIP and GRUU
RFCs. I hope someone can give me more insight.
My SIP application registers some SIP instances at a customer's SIP
server and receives a public GRUU for each of these instances.
After registration the SIP server se
