On 4/18/19 8:00 PM, anhright wrote:
Hi Paul,
My concern is not about fax machine, it is about my system when it
receives re-INVITE with no precondition, but it adds precondition to the
200 OK.
Putting them in does no harm. But it may indicate problems if it expects
something to happen as a result.
Thanks,
Paul
Thanks,
A.C
Sent from my Samsung Galaxy smartphone.
-------- Original message --------
From: Paul Kyzivat <pkyzi...@alum.mit.edu>
Date: 4/18/19 23:21 (GMT+07:00)
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Precondition is added into 200OK re-INVITE
On 4/17/19 10:50 PM, Anh Cao wrote:
> Hi all,
>
> I meet a weird case with precondition but can not find any document talk
> about it:
>
> I make SIP call from my system to the fax machine. In the initial INVITE,
> my system includes precondition in Supported header and status in
SDP. But
> fax machine does not support precondition so it removes precondition from
> Supported header and status from SDP.
>
> After voice call is established, fax machine sends T.38 re-INVITE to my
> system to start fax with Supported header has no precondition and SDP has
> no status.
> And my system answers fax machine by 200 OK with Supported has
precondition
> and T.38 SDP has status for precondition:
> m=image 55314 udptl t38
> a=T38FaxVersion:0
> a=T38MaxBitRate:14400
> a=curr:qos local sendrecv
> a=curr:qos remote sendrecv
> a=des:qos none local sendrecv
> a=des:qos none remote sendrecv
>
> Is it the acceptable behavior? and there is any document talk a bout this
> case? with re-INVITE for voice all and for fax call, the behaviors
are the
> same or different?
I don't see anything wrong with this. The "Supported" is declaring your
*support* for preconditions. The fax machine is acting as it should
given that it doesn't support or understand preconditions. It is
apparently ignoring the a= lines carrying precondition status, which is
what an implementation is supposed to do with attributes it doesn't
understand.
What else do you think should be done?
This is basic behavior for extensions.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
