| Summary: | ASTERISK-17027: On session-timers refresh, after 422 response Asterisk set modified From/To/Contact on next re-INVITE | ||
| Reporter: | Sergey Dremlyuzhenko (sergeykrd) | Labels: | |
| Date Opened: | 2010-11-25 14:02:56.000-0600 | Date Closed: | |
| Priority: | Minor | Regression? | No |
| Status: | Open/New | Components: | Channels/chan_sip/Interoperability |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) call_log.txt ( 1) sip_call_trace.pdf | |
| Description: | Call was established from Panasonic PBX to Asterisk over SIP trunk. In this call asterisk has 'session-refresher=uas' which made refresher role to swap after each refresh. After some refreshes, Panasonic declined Session-Expires: 90 (which it offered first) with 422 response - it is strange but it is not violate RFC4028. Then Asterisk sending another re-INVITE with modified Session-Expires (this is ok with part 7.3 of RFC4028) and modified (or more like 'resets') From/To/Contact. Last is SHOULD NOT be modified (same part 7.3 of RFC4028), unless knowing what doing. So after that INVITE Panasonic starts new call. In spirit of RFC4028, Asterisk should not modify this fields on INVITE/422-INVITE. ****** ADDITIONAL INFORMATION ****** This bug was checked at 1.8.0 release as well as on latest SVN. At actual call Panasonic was under NAT, but it was checked without NAT as well. Attached files have full sip trace (text file) and call flow (pdf). | ||
| Comments: | By: Jorrit Kronjee (jorrit at infopact nl) 2010-12-14 10:22:55.000-0600 We are facing similar problems on asterisk 1.6.2.13 with ... tum tum tum .. a Panasonic PBX as well. Looking at the code we noticed that the proc_422_sp calls transmit_invite(), while I believe this should be transmit_reinvite_with_sdp(). This would also explain the reset of other headers. We will investigate this later this week, but it would be much appreciated if anyone could give us any pointers on why transmit_invite() was used in the first place. | ||